Community
Participate
Working Groups
I observed that bundles from http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/development don't have a version timestamp. They are versioned 8.0.2.SNAPSHOT. I think, even for development/nightly builds it is crucial to be able to distinguish them. They should therefore have unique version numbers.
I am aware of this issue. One of the side effects is that tycho builds will keep the cached nightly snapshot bundles instead of upgrading. I am worried about rushing a change in the current versioning of the bundles: In particular released jetty versions use a v${datestamp} scheme and we must make sure that the snasphot versions will be easy to distinguish from the releases and also have always a lower version than the releases. So here is the scheme for the qualifier of a snapshot I would suggest: n${datestamp}-${timestamp} 'n' stands for nightly. We can't use 's' as it usually means 'stable' in the eclipse world. Comments and suggestions welcome. We are not the only ones facing the issue. In fact the next OSGi spec will improve this: http://dev.eclipse.org/mhonarc/lists/tycho-user/msg01012.html
All of the Eclipse projects I have seen use a date+time-stamp for each build, regardless what type of build. Some use a letter to distinguish build types. E.g. RAP uses 'N' for nightly builds, Platform/UI uses 'I' (=integration) for nightly builds. Others don't use a leter but just the date- and timestamp. How about also using date+time-stamps (with ot without build type letters) for release builds? That way each build can be uniquely identified. The current situation with the SNAPSHOT build is unpleasant. Without clearing the cache it is not possible to update to a newer version. In a shared environment like build.eclipse.org, a 'random' build gets stuck in the cache. And to reset the cache you have to ask the webmasters.
SNAPSHOT in the qualifier is still valid, as a "8.0.2.{datestamp}-{timestamp}" is indistinguishable from a release build of that artifact. Now, indicating the development time nature of the artifact such as "8.0.2.SNAPSHOT-{datestamp}-{timestamp}" is still clear enough that the build is a development time snapshot with warts and all, not a release quality build. Seems that eclipse conventions use a 'm' to indicate milestone "{version}.m{datestamp}-{timestamp}", but that has project management implications that confuse things. If you want short, consider the idea of marking it as a nightly, "{version}.n{datestamp}-{timestamp}" then. Note: maven SNAPSHOTS automatically take a "{datestamp}.{timestamp}-{build}" when deployed to a snapshot repository. eg: https://oss.sonatype.org/service/local/repositories/jetty-snapshots/content/org/eclipse/jetty/osgi/jetty-httpservice/8.0.4-SNAPSHOT/jetty-httpservice-8.0.4-20111013.135633-1.pom
n{datestamp}-{timestamp} seems reasonable to me
I don't want to see date/time stamps on the normal development builds. However, if you look in the staged repository, https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/jetty/jetty-server/7.5.4-SNAPSHOT/ you will see that maven already builds snapshots with timestamps. eg jetty-server-7.5.4-20111013.030443-1.jar Can't we make the OSGi bundles consume specific ones of these? At the very least, we should adopt the same naming convention.
Greg, this is just for bundles in the p2 repositories we produce from Hudson. The builds on there currently make development releases labeled as the text snapshot. So any version here would only be for behind the scenes inside p2 and will never really see the light of day. They don't touch oss.sonatype ever.
Oh, and these are separate to the ones that we release on jetty releases as well, purely for people consuming or paging nightly development builds
(In reply to comment #5) I thought about reusing the timestamps that maven produces, such as jetty-server-7.5.4-20111013.030443-1.jar But the version id "7.5.4-20111013.030443-1" violates osgi version naming/syntax rules. "#.#.#.qualifier" is what you should use. The part "4-20111013" will trigger an invalid version in osgi as the dash is there.
I don't believe we are generating and publishing snapshot/nightly osgi bundles any more, just for the releases. Jan
