aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Versions (leading on from releases discussions)
Date Fri, 04 Feb 2011 23:56:39 GMT
I don't that this way of doing things is scalable enough, but that may
be just me.
Or it could if we have much more coarse grained bundles that we
currently do (for example, just keep the uber bundles and move
everything else as plain jars).

On Fri, Feb 4, 2011 at 23:30, Felix Meschberger <> wrote:
> Hi,
> To me bundle versions are for targetted at humans: They convey the
> evolution of the bundle as a whole:
> * Increment the micro version if you fix a bug
> * Increment the minor version if you add functionality
> * Increment the major version if you potentially break
>    backwards compatibility or added the next revolution.
> To the OSGi framework the bundle version is basically irrelevant (unless
> you use the dreaded Require-Bundle ...) [well not really, but sort of].
> I think the only real requirement I would place on bundle version
> numbers is to not release (and thus increase the version number) if
> there is no change. So there should not be a version x and a version y,
> where x != y, of a bundle B which are identical. This is confusing.
> As for packages: version numbers of exported packages IMO and according
> to the OSGi semantic versioning whitepaper convey about the contract of
> the package. As such package versions are almost never the same as
> bundle versions (well, maybe they are equal in the first release....).
> Like bundle versions, package versions should not be changed if there is
> no change in the package. This would not only be confusing but only be
> detriment to configuring system.
> So, my advice is to version packages and bundles independently according
> to the needs bundle development. Don't try to keep versions in sync.
> This will not work.
> At the end of the day un-equal version numbers are a matter of life (or
> do you sync with XML APIs, Lucene, Derby, JTA API, etc... ?). Over time
> you will get used to different version numbers and it will be natural.
> Actually, what you gain be not requiring synced version numbers if
> increased freedom in evolving bundles: some bundles are more stable than
> others. So be it and enjoy this situation ;-)
> Regards
> Felix
> Am Freitag, den 04.02.2011, 18:50 +0000 schrieb zoe slattery:
>> Hi - I had a very useful IRC discussion with Guillaume trying to make
>> sure that we had a common understanding of the versioning policy that is
>> used in Aries today and the implications of changing it to use OSGi
>> semantic versioning for packages, and maybe for bundles.
>> I believe we agreed that we do not use package versioning correctly at
>> the moment and, in order to do so, we would have to break the way that
>> that package versions are derived from bundle versions and manage
>> package versions independently (manually).
>> We didn't agree on the right thing to do with bundle versions (we didn't
>> disagree either, I just don't know what the right answer is) , in
>> particular where a module has a set of sub-modules (bundles). The
>> options are either:
>> 1) To agree not to follow  bundle versioning policy. So all teh
>> submodules in a module would have teh same bundle version irrespective
>> of whether they have changed.
>> 2) To follow it and try and cope with what could become an unholy mess
>> of bundle versions in the development code base.
>> I tried to draw this out in a set of charts, here:
>>, and
>> I've just realised that not everyone will have odp so I'll put a pdf in
>> there too.
>> These are for discussion and illustration of the problem - feed back
>> welcome.
>> Zoe

Guillaume Nodet
Open Source SOA

View raw message