The arguments of 'Maybe this would cause problems' don't really seem to be borne out by the Maven repository, which has over 400G of versioned artefacts that have gone through the -SNAPSHOT process during development and rarely, if ever, has any problems in versioned code. (That's not to say mistake can never happen; but it's easy enough to publish a new asset with a new patch version if required, as has been done occasionally before such as the javax.jms releases.)

The problem with the existence of the OSGi build qualifier is that it means Eclipse developers don't actually take care to version code properly. Instead, the build process just spits out recompiled bundles, often without a corresponding bump in version number where required or needed.

The issue is whether or not SNAPSHOTs shold be built in a 'lower' numerical namespace using 1.2.3-456 which sorts less than 1.2.3. By encouraging a difference between 'unreleased' and 'released' versions, it becomes clear whether there are changes which are important, and allows developers to report bugs against a specific version (instead of just 'the latest version').

According to both the Semantic Versioning and the Eclipse Version Numbering rules, the patch number (third segment) should be changed whenever there is a difference between build artefacts. As I've listed on the InfoQ article, that plainly doesn't happen in some cases:

• org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
• org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
• org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
• org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
• org.eclipse.core.variables_3.2.500.v20110511.jar
• org.eclipse.core.variables_3.2.500.v20110928-1503.jar
• org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
• org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
• org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
• org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
• org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
• org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
• org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
• org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
• org.eclipse.jface_3.7.0.I20110522-1430.jar
• org.eclipse.jface_3.7.0.v20110928-1505.jar
• org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
• org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
• org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
• org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
• org.eclipse.ui_3.7.0.I20110602-0100.jar
• org.eclipse.ui_3.7.0.v20110928-1505.jar

The point of showing the cross-section of the above is not to highlight specific projects, but to show this is a widespread problem that goes across all projects. The problem is, there is no 'penalty' for leaving a 1.2.3.qualifier as the Manifest entry and just spinning out builds with new build qualifiers in place.

The key advantage of having a different version numbering format between release versions and pre-release versions is to ensure that at release, the version number is updated appropriately. This means that the development process generally follows:

• Create 1.0.0-SNAPSHOT for development
• Do work
• Release 1.0.0
• Update version to 1.0.1-SNAPSHOT
• Do work
• Release 1.0.1 or 1.1.0 (or 2.0.0) as appropriate
• goto 10

The decision as to what to call the next number can either be tracked by updates to the -SNAPSHOT itself (e.g. moving to 1.1.0-SNAPSHOT) or can be deferred to later in the process. There's even tooling to help you do that (the mvn release plugin) -- though this just removes the -SNAPSHOTS for you rather than doing any semantic analysis.

This pattern is so common that it's even codified as a bullet point in the Semantic Versioning specification:

A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

The 'pre-release versions satisfy but have a lower precedence than' sums up the rule in a nutshell: in other words, anywhere a 1.2.3 is valid then all 1.2.3- are valid as well; anywhere a 1.2.3 is not valid then all 1.2.3- are not valid. So, in a range like [1.2.3,4.5.6) then any pre-release state of 1.2.3- is included, but any pre-release state of 4.5.6- is not included.

This was even implemented successfully in Equinox, with an implementation in 3.8M6.

Unfortunately, the concerns listed by the CPEG were out of touch with how developers work outside of the OSGi space, and instead of reaching out with a mechanism which would have been compatible for released artifacts (whilst providing a SNAPSHOT style build system that would not be loadable on older OSGi runtimes) it has been removed from the specification. Given that OSGi R5 is a major release of the runtime, this would have been the ideal time for introducing a new version syntax, and one that would have been quickly adopted elsewhere.

So instead of having 'memorable' artifact names like org.eclipse.ui_3.7.0.jar we'll be stuck with unmemorable names like org.eclipse.ui_3.7.0.v20110928-1505.jar for the forseeable future in the OSGi world. This causes more cognitive work for humans (trying to remember the name) whilst introducing more opportunity for mistakes (by releasing the same major/minor/patch with different builds).

This is what I refer to as humans solving the tooling problem, rather than the other way around.

Today's keynote is on the Future of ALM, a look at how the recent advances in application lifecycle management tools have enabled much tighter integration between developers and the IDEs themselves. Should be an interesting view as to where these tools are going over the next few years.

Today's OSGi experience kicks off with a modular and extensible OSGi shell, which is a look at the new Gogo shell from Apache Felix. This shell will become the default one for Eclipse Juno, and is already available in the existing milestone builds. Gogo is a powerful shell and can do a much wider range of things than the old Equinox one, but takes a bit of retraining the muscle memories when it comes to controlling it (for example, lb instead of ss to list bundles instead of show status). There's also a couple of presentations on Virgo Experience and a Path to Modularity with Eclipse Virgo, both of which provide a managed OSGi runtime environment (with web admin tools) and can be used as a replacement for existing Apache Tomcat engines thanks to the integration with the Tomcat web bundle.

Another must-see presentation is the one on Eclipse Xtend. This is a language, built upon the runtime tools of Xtext, which 'compiles' down to Java source code, and thus fits in with existing Java build tools. Although it's possible to commit in the Java code (and just use a headless Java compiler) it is also possible to commit the Xtend source files and use the Maven plugin to compile the code as part of the build. The upcoming 2.3 release provides a way of debugging from source (rather than the generated Java code) as well as some refactoring support. Unlike other languages, since Xtend doesn't have its own compiler it has less bugs and faster build times than more complex languages. And, it's backwardly compatible across JVMs and releases, something which can't be said for some popular JVM based languages. There's a follow up on Xtext best practices later in the day as well.

There's a talk on News from Git in Java Land which is by a couple of the core EGit/JGit developers, whose only problem is that it overlaps with the talk above. Still, if you're into Git then this will be a good state of the union; there's also a talk on automatic remote project synchronisation using Git later as well.

My final pick for the day is on the time travelling debugger, which won the best tool at this year's award winners. If you've never seen this in action before, then this talk is going to open your eyes as to how much data it's possible to derive from a runtime system.

As this year's EclipseCon comes to a close later on today, I'd like to once again echo my thanks for the community award. Hopefully I'll be able to be back one day for EclipseCon!

Today's OSGi sessions include Enterprise OSGi best practices, Enterprise OSGi for Earthlings, and OSGi in the Cloud. Later on in the day, there's a presentation on the Apache Felix Web Console, which is used in the Apache Karaf project. The final one is Equinox and Vaadin. For those that don't know, Vaadin is a UI framework -- there's a set of demos available if you want to see more.

Sadly, the How GitHub Works talk has been cancelled. I was fortunate to attend Zach's talk at QConLondon, and I wrote up some notes on my blog at the time.

There are a couple of Orion related presentations today; if you haven't seen Orion, then you can find out more at the Orion project page, which includes a demo project you can use to edit the content. There's an OrionHub which you can create an account via the getting started page. The LAnguage Tooling in Orion presentation will look at the state of language development, with a focus on the JavaScript tools. Later on, there's a talk about developing cloud apps with Orion.

For those who still haven't made the leap to Git yet (and are one of the 48% not using Git yet) then the Lets Git The Party Started should be a good introduction to how to use Git effectively within Eclipse. You may also like to read my Git for Eclipse users piece, which subsequently got folded into the official EGit documentation, as well as my (now finished) Git Tip of the Week series. There's also a talk on Gerrit under the 'Harnessing Peer Code Reviews' title. a

Finally, there's a great intro to Xcore, described by (EclipseCon lifetime award winner) Ed Merks as "Ecore meets Xtext", as well as Building GUIs with WindowBuilder. Eric Clayberg has been working on WindowBuilder since before its acquisition by Google, and has recently become open sourced after having been contributed to Eclipse.

Don't forget the BoFs tonight, as well as GitHub's sponsored showcase and reception.

More seriously, I'd like to thank Lars for nominating me for the Top Contributor award and for everyone who has voted for me. It was a real surprise to me as I didn't even know the nominations were there.

It's a pleasure to use and write about Eclipse and be part of the community. I hope to continue on in the next decade in much the same as the last decade, although hopefully I'll be able to make it back to an EclipseCon sometime in the near future.