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. 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. 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). 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... 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
