> I think we may want to stick too much to semantic versioning. Don't > get me wrong, I agree with the compatibility rules semantic and we > should support them: i.e. if there is an incompatible change, the > major version has to be different and if there is a compatible change, > the minor version has to be different. > However, I think it does not imply we need to be strict about *when* > we change the version of the package. If we align the package version > changes with the bundle version changes (that does not necessarily > imply they have to be the same), i.e. when we change from aries 0.3 to > aries 0.4, the packages are bumped too from a minor version, this > leaves some place to do branch fixes using minor versions on the > package.
I am a strong -1 for this. Doing this means that you can't mix bundles from different releases and you can't reliably write a plugin for our projects. If we start incrementing package versions for no reason then people who implement our APIs will be broken by every release. Regards, Tim ---------------------------------------- > Date: Sat, 5 Feb 2011 13:38:42 +0100 > Subject: Re: [DISCUSSION] Using packageinfo to set package versions > From: [email protected] > To: [email protected] > > I think we may want to stick too much to semantic versioning. Don't > get me wrong, I agree with the compatibility rules semantic and we > should support them: i.e. if there is an incompatible change, the > major version has to be different and if there is a compatible change, > the minor version has to be different. > However, I think it does not imply we need to be strict about *when* > we change the version of the package. If we align the package version > changes with the bundle version changes (that does not necessarily > imply they have to be the same), i.e. when we change from aries 0.3 to > aries 0.4, the packages are bumped too from a minor version, this > leaves some place to do branch fixes using minor versions on the > package. > > I think we face two different development model basically: > > * use a more traditional development model using a tree of versions > (either at the component level or for the whole tree). We can support > branch fixes and micro releases in a tree. We need to somewhat align > the package version changes to the bundle version change. This means > we may end up with multiple identical packages with the same version > number (though I suppose real api and library packages are somewhat > different, as pure API packages that do not contain any code could > have their own versioning not tied to this). We can release / branch > per component or from the root (still to be decided, but completely > orthogonal to the problem) > > * use the model that felix / sling follows and have a versioning > scheme per bundle with no way to maintain bug fix branches. Each > bundle has to be released independantly with its own release notes and > all. I think we'd have to flatten our svn tree as there's no real > need to have a tree of modules (we can use maven profiles if we want > to build only a given component). The consequence is that we also > need to maintain documentation about compatiblity, as users see the > bundle versions, not really the package versions and we need to have a > way to tell them which bundles are supposed to work together (i think > we have more than 100 bundles in the whole tree I think, so not sure > what kind of documentation could give an overview of that ;-) ). > > It seems any in-between solution has some big problems. Currently, > we're more on the first solution and I think it's way easier for us > and for our users. > > On Sat, Feb 5, 2011 at 11:03, Felix Meschberger wrote: > > Hi, > > > > Am Samstag, den 05.02.2011, 00:43 +0100 schrieb Guillaume Nodet: > >> > 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. > > > > +1 ! > > > > (Not sure, whether the Bundle Plugin does not get overloaded, though) > > > >> > >> > >> 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 ? > > > > Well branches pose just more than this single problem, which is why I > > generally try to avoid release branches like the plague ... > > > > In this concrete example, you might probably have to either backport > > everything from the bar/1.0.1 package or employ qualifier increments. > > > > At the end of the day, this should not prevent the project from adopting > > semantic versioning, because the benefits tremendously outweigh these > > minor costs. > > > > Regards > > Felix > > > >> > >> > >> >> 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: > >> >>> > >> >>> > >> >>> ${project.build.sourceDirectory} > >> >>> > >> >>> **/packageinfo > >> >>> > >> >>> > >> >> > >> >> Unfortunately, you will still have the regular resources in the > >> >> src/main/resources tree. So you have to explicitly list this to in the > >> >> 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
