plug-in bundle development environment makes an assumption that all bundles, everywhere, should start at version 1.0.0 whether that makes sense or not. Even the well-documented version numbering document lists 1.0.0 as an example, and that has been assumed to be the de facto standard.
The problem with this approach is that not everything starts out life as a 1.0 product. Not only that, but OSGi's versioning scheme is an ever-incrementing one; once you go 1.0.0, you can't go back. As soon as you release code with a 1.0.0 version, you have to keep incrementing the version from there. And if it's something as a work-in-progress — like ObjectivEClipse — then potentially confusing users with a 1.0 moniker on a clearly alpha product won't do you or your product's reputation any good.
At this point, it's worth taking a step back to observe a few things:
- 0.0.0 is both the 'default' version (if one is not specified) and the lowest number you can have, as per the OSGi spec. From this number, you can go up to any version you want, but there's no down to go to.
- The suggested versioning use (both by the OSGi spec and Eclipse's version numbering scheme) is to treat major breakages as an increment to the major number (first digit); any new (but backward compatible) externally visible features are an increment to the minor number (second digit), and any patches or updates are an increment to the service number (third digit).
- Initial versions of items are never, never complete. Unless the code has been developed in-house by a coloured company and then donated to Eclipse en-masse, all code starts with a single line. Pretty much every build cycle will introduce new features; backward compatibility is something to hope for rather than a solid guarantee; and what you end up with for your first release almost never ends up looking like it started with.
- The Eclipse versioning system, whilst comprehensive, isn't really followed by the integration (or nightly) build process in any case. In fact, all the distinctions between different bundles use the lexicographic qualifier, with an encoded date format, against the same OSGi version for most of the build. If lucky, this will be upped just prior to the release train instead of as a delineating factor during development. Partially, that's so the final Eclipse version (3.4.1) corresponds to the version of the bundles when the release candidate happens.
So a lot of how PDE works, and how the bundles are built, are direct artefacts of how Eclipse's release engineering train works, rather than actually following separate build streams for individual bundles. Quite a lot of that is based on the date encoded in the lexicographic qualifier; if the versioning was being followed for each integration build, you'd expect each
minor service* version to be incremented if following the versioning document explicitly. (At this point, an argument will break out about whether (a) the interim products (nightlies, integration) should even be versioned, or (b) having such dependencies would allow consumer bundles to demand at least a minor level to absorb bugfixes, or (c) whether Eclipse's release train process/tools are something one should copy. Feel free to discuss; they're not relevant to the point in hand anyway.)
So, if PDE is trying to lose its P moniker and end up with a B moniker instead, why doesn't it default to creating bundles with a 0.0.0 qualifier? Bug 277082 is open for comments, though this late in the release cycle (you know, the one where you're supposed to be testing for and filing bugs) is pretty much guaranteed to be ignored for Eclipse 3.5. I almost fell for this in the 0.1 milestone release for ObjectivEClipse, and just when I was generating the non-p2 enabled update site (i.e. it works) I discovered that I'd unwittingly created a 1.0.0 monster. I plan to add more new features that are externally visible in the next milestone, so going from x.y.z to x.y+1.z was always going to happen anyway, but starting from 1.0.0 is a bit of a historic artefact from the pre-OSGi days.
Lastly, even Eclipse 3.5 has some 0.x.y versions buried in it. ECF's bittorrent provider is at 0.3.x (at least, as of Eclipse 3.5M5 which I have on this machine - might have moved forwards since) and the JSch bundle (used for secure shell) follows the developer plugin version of 0.1.x as well. So basing the 1.0.0 on "that's the way we do it" doesn't really hold water - there's nothing in the version numbering document that mandates an initial 1.0.0. In fact, probably the only reason why there are so many 1.0.0 bundles in Eclipse is purely to do with the default in the PDE UI that makes a 1.0.0 the initial starting point from which you can never go down.
* Update: thanks to Ian Bull for pointing out I meant 'service' instead of 'minor' in the integration builds