2015-12-07 21:02 GMT+01:00 David Bosschaert <[email protected]>:
> Hi Michael, > > I would imagine that one of the following is true: > > 1. Typically changes made to maintenance branches are limited to > bugfixes or implementation details (e.g. optimizations), which would > not have a bearing on the exported package versions. > This kind of change happens quite frequently. > 2. If there is a change made to API in the 1.4 branch that is backward > incompatible with the current code, then the same change should really > be made in the 1.5 branch to keep API users working in the future, > which keeps the exported package versions in line - you make the same > version change in the 1.5 branch as in the 1.4 branch. 3. It is hard to think of a situation where an API change is made to > 1.4 which will not be available in future versions and I've never come > across such a situation in reality. However if you have such a > scenario you could change the major version of the package to > something unusually high, e.g. 10000. Major package versions can be > thought of as distinct entities so if the current version of your > package on the maintenance branch is 2.1 and you make a backward > incompatible change that you won't support in the future, you could > choose such a high version for it. > The more frequent case is a change in the development branch (1.5) that has to be backported to the maintenance branches (1.4, 1.2, 1.0). If the change breaks the API of the affected packages, it could be troublesome - see below. > > 1 and 2 above should be pretty simple and 3 should pretty much never > happen anyway... > > Two additional notes. While we're talking about 'Oak 1.4' I assume > that is the version of the bundle. I assume each package in that > bundle evolves independently which means that they could have versions > other than 1.4 (e.g. org.apache.foo = 1.1.2 and org.apache.bar = 1.3 > etc). > Packages evolve independently, but they do in potentially divergent branches. This is the kind of timeline that we usually face: - Oak 1.4 has a package org.foo.bar 1.0 - Some changes happen on the development branch 1.5 - Oak 1.5 now has a package org.foo.bar 1.1 - A change X happen in the development branch 1.5 - Oak 1.5 now has a package org.foo.bar 1.2 - The change X has to be backported to the maintenance branch 1.4 - Oak 1.4 now should have a package org.foo.bar 1.1 Assuming that the versions were incremented following the semantic versioning rules, we now have two packages - both called org.foo.bar and both having version 1.1 - that live on two different branches and contain different code. The only obvious solution that comes to my mind is to bump the major version of every package right after the development branch 1.5 is started, but I don't like this approach very much because it would break compatibility with existing clients for no obvious reason. > Also, the evolution of the *bundle version* does not necessarily have > to reflect the version of the packages inside the bundle. While some > people like to reflect some of the API evolution in the bundle version > number other people simply increase that monotonically or using some > marketing scheme or something like that. Semantic versions are really > important for import package ranges so the exported packages should be > semantically versioned. But people generally don't use ranges to > require bundles so how these are versioned is a matter of taste... > Oak doesn't use bundle versions to convey any kind of useful information to its users, it's more of a marketing scheme. Versions evolve semantically for packages, though. > > Just my 2c, > > David > > On 7 December 2015 at 17:24, Michael Dürig <[email protected]> wrote: > > > > Hi, > > > > We started to annotate packages with their export versions (aka. semantic > > versioning [1]) a while ago. After the 1.2 release we enforced proper API > > management through the baseline functionality of the Maven bundle plugin. > > This means that on current trunk the build fails should an API change but > > the related package export version is not reflecting this. > > > > So far this approach worked relatively well. Going forward however I > presume > > things to get more complicated. Once Oak 1.4 is out we are going to have > to > > maintain a 1.4 branch while continuing development on trunk (i.e. 1.5). > With > > this we suddenly will have two potentially diverging branches, which begs > > the question on how to do release from these branches while at the same > time > > maintaining consistent semantic versions of the contained packages across > > the branches? > > > > Michael > > > > > > [1] http://www.osgi.org/wp-content/uploads/SemanticVersioning1.pdf > > [2] https://issues.apache.org/jira/browse/OAK-2006 >
