aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: [DISCUSSION] Using packageinfo to set package versions
Date Sat, 05 Feb 2011 09:45:40 GMT
On 05/02/2011 08:31, Alasdair Nottingham wrote:
> You have hit onto the problem with semantic versioning. It works just fine for a linear
version stream, but not a tree.
Would it be such a big issue to do everything from trunk? I'm not 
convinced that it would _if_ we use semantic versioning properly.
> I've been thinking this over for a while, but I can't see a good solution. We could potentially
say you don't do a micro increment in trunk, only minor, but this doesn't really work properly.
No :-) - it doesn't.
> Alasdair Nottingham
> On 4 Feb 2011, at 23:43, Guillaume Nodet<>  wrote:
>> On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham<>  wrote:
>>> Alasdair Nottingham
>>> On 4 Feb 2011, at 22:13, Felix Meschberger<>  wrote:
>>>> Hi,
>>>> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham:
>>>>> Hi,
>>>>> Currently we specify versions of exported packages in the pom. This is
>>>>> not ideal as it means whenever anyone makes a change in a package they
>>>>> have to edit the pom,
>>>> You could argue that modifying exported packages is critical, so making
>>>> it harder to do might get people to think twice ... Granted this is kind
>>>> of a weak argument ;-)
>>> In fact I want it to be easy, the easier the better. If you change the code the
version should increment.
>> So why even bother with having to manually change the version ? I
>> think it should be possible to have the maven-bundle-plugin increment
>> the version depending on the kind of changes by comparing the package
>> signatures and make sure it follows the semantic versioning.  Given it
>> has already been done (see
>> I
>> think we could add that to the maven bundle plugin.
>> However, there's something which is worrying me about the semantic
>> versioning.  I don't think it can cope with maintenance branches.  The
>> process of incrementing a package version works well in a single line
>> of releases, but not in a tree, so can't ever release a package which
>> doesn't contain all the previous changes.  Or rather the process works
>> for a given package, but the problem is that our bundles do not only
>> contain a single package.  Let's take a concrete example.
>> I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0.
>> In a future release 3.1 of that bundle, i add one functionality to the
>> foo package and a minor modification to the bar package, so I release
>> this with foo / 1.1 + bar / 1.0.1.
>> Some time later, I find a bug in the bar package which I'd like to fix
>> for both minor versions of my bundle.  If I do so, I'd end up with a
>> bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo
>> / 1.1 + bar / 1.0.2.  That's not really possible because the two bar /
>> 1.0.1 package would be different.
>> Possible solutions:
>>   * backport into 3.0 branch the change that modification that caused
>> the bump from 1.0 to 1.0.1 (when releasing 3.1).   However, this may
>> not be a big fix, maybe a small improvement that I don't want to
>> backport, so I don't think this solution is a good idea
>>   * never release a bundle which exports multiple packages: that sucks too
>>   * don't do maintenance release: i don't think we want that
>>   * consider that any modification you may not want to backport in a
>> maintenance branch later should lead to bump the minor version of a
>> package, even if the signature of the package doesn't really change
>> I think the last one is the only one applicable.  Thoughts ?
>>>> On the other hand, the problem is always the same: you have to update
>>>> information in a secondary location -- regardless of whether this is the
>>>> packaginfo or the pom.xml file.
>>> Right, and packageinfo is right next to the classes you just updated, closer
= better IMHO.
>>>> The advantage of doing it in the pom.xml file IMHO is that you have a
>>>> complete overview of your exports incl. their versions. YMMV.
>>> The downside in our case is you have to update the bundle and the uber bundle,
bigger chance of getting out of sync, which would be very very bad.
>>>>> also you need to sync the version correctly
>>>>> between the bundles
>>>> the bundle plugin takes care of this (fortunately) -- assuming you mean
>>>> the "Import-Package" versioning.
>>> I'm trying to address export bundle. I'm happy with the import package stuff.
>>>>> and the uber bundles.
>>>>> bnd supports the packageinfo files (and also annotations in
>>>>>, but those are not currently picked up and used in
>>>>> our build. I raise FELIX-2819 and a workaround has been suggested,
>>>>> which I managed to get working.
>>>>> The fix would be to add the following to the default-pom and get the
>>>>> modules to use the updated parent:
>>>>>             <resource>
>>>>>                 <directory>${}</directory>
>>>>>                 <includes>
>>>>>                     <include>**/packageinfo</include>
>>>>>                 </includes>
>>>>>             </resource>
>>>> Unfortunately, you will still have the regular resources in the
>>>> src/main/resources tree. So you have to explicitly list this to in the
>>>> <resources>  element of the parent POM to not miss these...
>>> Right, this is already in our parent pom, so I'm proposing adding this in addition
to the other resources statements already there.
>>>> In Sling we currently maintain the exported package version in the POMs.
>>>> This works fine but is also kind of suboptimal.
>>>> I think the most important thing is to make it consistent: Do it either
>>>> way, but stick to.
>>> I agree. I think we should use packageinfo though :)
>>>> Regards
>>>> Felix
>>>>> Thoughts?
>>>>> Alasdair
>> -- 
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

View raw message