Re: [jgit-dev] version numbers

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

onsdagen den 5 maj 2010 02.11.33 skrev  Matthias Sohn:
> this should be on the list
> 
> ---------- Forwarded message ----------
> From: Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>
> Date: 2010/5/3
> Subject: Re: helios and ramp down plan
> To: "Shawn O. Pearce" <spearce@xxxxxxxxxxx>
> Cc: Chris Aniszczyk <caniszczyk@xxxxxxxxx>
> 
> 2010/5/3 Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> > Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx> wrote:
> > > 2010/5/3 Chris Aniszczyk <caniszczyk@xxxxxxxxx>
> > > 
> > > > > We also need to decide on the version number, looks like it needs 4
> > > > 
> > > > digits
> > > > 
> > > > > and 0.8 is already gone, right ?
> > > > 
> > > > So the Eclipse/OSGi way of handling versions is you always build
> > > > 0.8.0.qualifier and then one of those builds you just tag as being
> > > > the "0.8.0" release. Note that this is mostly a marketing name...

OSGi makes a differense between 0.8.0 and 0.8.0.qualifier in that the first
preceed the other. The major problem is that maven treats this the other
way. Always having the qualifier in the  version is just laziness because
it requires extra work to either alter the build or have more advanced
scripts. I think the release version should not have a qualifier, or as a
compromise, a special qualifier like "release" for versioning compatibility. 
The extra work for modding the builds can be done via a script.

> > > > your 0.8.0 release just points to a specific 0.8.0.qualifier
> > > > version. Does this make sense? I think what we're doing is fine
> > > > currently. Unlike last release, we shouldn't patch things to remove
> > > > the qualifier, we should simply patch to change it to 0.9.0 when we
> > > > open up HEAD. I don't know if this works with the Maven way of doing
> > > > things though.
> > > 
> > > AFAIK Maven assumes that released versions have 3
> > > digits <major>.<minor>.<micro>
> > > hence there would be 2 options :
> > > - have a 3 digit release number like we did with 0.7.1
> > > 
> > >   this is clearer since same version means same version not regarding
> > >   if
> > > 
> > > it's
> > > 
> > >   a maven pom dependency or an OSGi dependency but it brakes the 4
> > >   digit
> > > 
> > > rule
> > > - have a 3 digit release number for maven references and a 4 digit
> > > number for OSGi version
> > > 
> > >   this way the 4 digit rule for Eclipse is fine but it's not obvious
> > 
> > which
> > 
> > > jgit bundle version
> > > 
> > >   is equivalent to the corresponding maven artifact we upload to maven
> > 
> > repo.
> > 
> > FWIW, the Jetty project has been trying to make both happy by
> > making their Maven artifacts be versioned like 7.0.1.v20091125,
> > where the OSGi bundle version is also 7.0.1.v20091125.
> > 
> > I hate this numbering scheme.  As a consumer, its hard to know what
> > the release version is that you should be using.  Its nicer when
> > the project is able to commit to a particular number and declare
> > "this is the release".
> > 
> > For our next release, I guess we can just tag 0.8.0 in Git to point
> > to the particular revision that is our 0.8.0 release, but let the
> > qualifier remain in the sources.
> > 
> > However, the Maven build will still be messed up because our
> > pom.xml's will have -SNAPSHOT suffixes, which is not what a consumer
> > wants.  We'd still have to generate a custom Maven build by hand
> > by editing the -SNAPSHOT suffix to get a stable build registered
> > in the release Maven repository.  Given that our production builds
> > are created by Hudson CI... we need that to be in our source tree
> > as a source revision that Hudson CI can checkout and build.
> > 
> > That brings us back to... editing the sources like I did for 0.7.0
> > and 0.7.1.
> > 
> > At which point we can also drop the .qualifier and get a clean
> > 0.8.0 version number in the JARs.
> > 
> > However, 0.8.0 is already "gone".
> > 
> > So my plan all along was to actually make our next release 0.8.1.
> > 
> > And immediately after, bump to 0.9.0, and our next release be
> > 0.9.1, etc.
> > 
> > So the .0 service level of any given version number is actually a
> > development snapshot that cannot be trusted for API stability.
> > 
> > .1 service level and later, the API is frozen and can be relied upon.
> 
> OK, let's do it this way, this looks like the best compromise.

Since versions are so complicated I think we should have the discussion
before decisions, rather than after.

The history of the .1 is in general, as our 0.7.1 proves. The release
gets out. People start using it and discover it is bad and so fixes are
released. This is an unintentional release, and I think we should
stick with that. 0.8.1 is bug-fix-relase not a version-number-fix-release. 
Always releasing a .1 version looks bad, like we could never get a release 
right.

Another scheme (I like is) 0.7.99.x for developement builds. Then the actual
release i 0.8.0. The odd-looking version signals to people that this version
cannot be trusted to compatibility or reliability.
 
-- robin