aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: internal version conflict in aries application (at least)
Date Thu, 02 Jun 2011 18:29:08 GMT
I am moderately hopeful that geronimo can use trunk however....

What I don't understand in this discussion is why a bug fix release to a pre-semantic-versioning-decision
release needs to have semantic versioning.  IIUC trunk has incremented at least the 3rd digit
on every bundle version and the bug fix would increment the 4th digit.... maybe not completely
correct but OK for me.

If this is going to cause problems then I think there was an important factor left out of
the semantic versioning discussion and I'd suggest that despite compatibility issues you need
to increment the first or second digit of all the trunk versions to allow room for bug fixes
on 0.3.  EIther that or rerelease the 0.3 code as-is with the semantic versioning scheme with
whatever numbers are correct so as to allow for bug fixes.

reading the there's an obvious problem
with bug fix releases if the trunk maven version is only updated on release.  This may be
what we're running into.

Consider a bundle released at bundle version 0.3.0.  The maven version of trunk will then
be 0.3.1-SNAPSHOT.  Suppose development proceeds on trunk and a method is added to an exported
interface so the package version is 0.4.0.  Now a bug fix branch is created from the 0.3.0
release tag. It's going to get released at bundle version 0.3.1.  What should its maven version
be?  I'd say 0.3.1-SNAPSHOT is pretty much the only plausible version.  In any case after
its released it is ridiculous to have trunk at 0.3.1-SNAPSHOT after 0.3.1 is released, this
would cause a lot of maven problems.

BTW there are a few places in that doc where -SNAPSHOT is left off such as....

For example, if proxy is released at version 1.0.0, the development version of proxy in trunk
will become 1.0.1.

david jencks

On Jun 2, 2011, at 10:51 AM, zoe slattery wrote:

>> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of
not paying close attention to the various discussions. But that doesn't mean we can't be discussing
now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
> Changing to use OSGi semantic versioning was complex and the subject of much discussion
on the list. I did most of Maven work to make it happen so I'm probably best placed to explain,
but even so it's complex. If you want to understand the rationale Alasdair gave a set of links
to earlier discussions, however a better place to start (where we started in fact) was to
read the OSGi alliance white paper www.*osgi*.org/wiki/uploads/Links/*SemanticVersioning*.pdf.
There is an important paragraph towards the end where bundle versions are discussed.
> Each bundle is now released separately as it must be if each bundle is to be versioned
separately. In the past we used a release by module scheme but the maven release plugin will
not handle having independently versioned submodules - so we had to abandon this way of working.
> At release time the version of each bundle is determined by comparing it (in particular
changes to packages) with the last released version. So - a bundle being developed at say,
0.3.1-SNAPSHOT might well get released at 0.3.1 or 0.4.0 depending on what had changed since
the last release. This is all documented on the web pages
> There are aspects of the scheme that we implemented that none of us like, we spent a
long time trying to improve on it. But, in the end we are an OSGi project and implementing
OSGi properly was more important to us than a simple release scheme.
> If you want to find some way to release from 0.3 and honour the OSGi versioning policy
that we implemented ... it might be possible. I can't think how and given that it took (iirc)
between 4 and 6 weeks of my time to switch us to semantic versioning I think you would be
better to take code from trunk because I think it will take less time.
> Zoe
>> --kevan

View raw message