You have hit onto the problem with semantic versioning. It works just fine for a linear version stream, but not a tree.
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. Alasdair Nottingham On 4 Feb 2011, at 23:43, Guillaume Nodet <[email protected]> wrote: > On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham <[email protected]> wrote: >> >> >> Alasdair Nottingham >> >> On 4 Feb 2011, at 22:13, Felix Meschberger <[email protected]> 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 > https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) 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 >>>> package-info.java), 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>${project.build.sourceDirectory}</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: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
