[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jgit-dev] version numbers
|
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:
> > > 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... 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.
--
Matthias
