aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: internal version conflict in aries application (at least)
Date Thu, 02 Jun 2011 21:12:29 GMT
On 2 June 2011 19:29, David Jencks <> wrote:
> 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.

We have to start somewhere. I think it will be confusing in some
"0.3.x" bundles are semantically versioned from the 0.3 release and
others are not. So if we were to say "ok lets do releases in 0.3 that
are not semantically versioned" would that mean we move everything up
to 0.4 and start from there? Then do we get similar pressure to allow
0.4 non-semanticly versioned changes. The change has to occur sometime
and we had decided it was with the 0.3 release.

> 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.

Personally I hope that when we do a 1.0 release of something it is
because the API is stable and we pass all relevant OSGi CTs. This
isn't the case for a lot right now so a major upgrade would be bad. A
minor could be made, but then we are, in my view, just postponing the
"issue" and some precedent can always be claimed to not follow the new
release process. Since aries is promoting a programming model for
enterprise OSGi I think we need to practice the rules we want apps to

> 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.

Yeah, In fact we haven't really followed this. Several modules have
gone to 0.4 because we know we have made API changes. I'm in favour of
doing it when you make the change and then having the release manager
validate we didn't do it twice. For instance an API package recently
was upped accidentally to 0.5 despite the last release version being

> 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.

I don't think that is the right flow. I think the right flow would be
you do work in trunk. You then need a 0.3.1 release, assuming trunk
hasn't broken APIs we release it as 0.3.1 and it moves to 0.3.2. This
works fine. At some point an API or breaking change is made and trunk
goes to 0.4. Then someone needs a bug fix. At that point we go to the
0.3.1 tag and create a branch from it, add the bug fixes and we
release from there. This way we never have 0.3.1 in a service branch
and trunk. We also only have a branch when we actually need the
release, we don't create one "just in case".

> 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.

I don't know if I understand these last two points, but it might be
because they are related to the previous one I just addressed. Sending
emails at 10pm probably isn't the best idea.


> thanks
> 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
>> 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

Alasdair Nottingham

View raw message