I've just been trawling through the archive and found the Version Policy discussion had in March [1] which is now enshrined in the versioning policy page on the Aries web site [2]. Back then we decided to follow this from Felix M:
On 17 March 2011 12:24, Felix Meschberger <[email protected]> wrote: > Hi, > > Am Donnerstag, den 17.03.2011, 12:08 +0000 schrieb zoe slattery: >> Hi >> > Hold on: lets first clarify which version of a bundle/module you are >> > talking of: >> > >> > * If it is the bundle/module's own version as specfied along >> > with the bundle/module's groupId and artifactId. >> > This version is switched to the next SNAPSHOT version by the >> > maven release plugin >> > --> I strongly suggest to keep this mechanism as is >> OK - I had though that it was better to leave the version in trunk being >> the same as the release version - but as I work through making the >> changes I can see that this will not work. In a perfect world I think it >> would be right to do this, but as you suggested I don't think we can >> count on people remembering to change the bundle version to >> something-SNAPSHOT when they first make a change. I'm having trouble >> remembering it as I go along :-) > > Right. > > There is another point to make: Your users would probably be confused to > see a release version number of trunk. Release version numbers are > generally expected on (immutable) tags while trunk is considered work in > progress and should be considered "modified" right from the start. > > Regards > Felix > >> > * If it is the dependency version of a bundle/module the situation >> > is more interesting and is probably what you are refering to. >> > >> > In the latter (dependency) case you have two situations: >> > >> > (1) you depend on new exported functionality of the dependency. In this >> > case upgrade the dependency when you need the new exported >> > functionality. >> > >> Agreed >> > (2) you don't depend on new exported functionality: refer to the lowest >> > release version providing enough exported functionality the bundle >> > requires. This ensures the import version is automatically set correctly >> > to allow for loose coupling supported by OSGi. >> Agreed >> > Regards >> > Felix So, based on the principal of trunk being modified from the start, the starting version of a module after a release version of x.y.z will be x.y.(z+1)-SNAPSHOT ... that's covered in Aries versioning policy [2]. What's not covered is what Felix described in (1) and (2) above, about when to bump up the version of a dependency a dependent has (point 2). So I'll add that to the Aries versioning policy page. Cheers, Jeremy [1] http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661.27234.33.camel%40meschbix%3E [2] http://aries.apache.org/development/versionpolicy.html On 9 November 2011 17:23, David Jencks <[email protected]> wrote: > Thanks for the clear explanation. I fully support semantic versioning :-). > After a day with the new versioning scheme I'm less worried it will cause > confusion, especially if we can get tool-supported semantic versions as > changes take place. > > david jencks > > On Nov 9, 2011, at 3:21 AM, Jeremy Hughes wrote: > >> On 8 November 2011 20:01, David Jencks <[email protected]> wrote: >>> Maybe you didn't mean exactly what you said as (a)? Now that there are a >>> bunch of released versions what exactly is wrong with e.g. blueprint-core >>> 0.4.1-SNAPSHOT rather than 0.4-next-SNAPSHOT? >> >> What I meant for a) is that during the mvn release:prepare phase >> you're asked what you want the version in the pom to move to after >> preparing the release. I know you know this, but for people who don't >> ... It defaults to the version you're releasing with an increment to >> the last number in the version string. So if you're releasing 0.3.2 >> then it'll default to 0.3.2-SNAPSHOT and that'll be what it checks >> into SVN. The thing is the no-one knows what version of the bundle >> will be released next. It could be 0.3.2, 0.4 or 1.0. By making it >> 0.3.2-SNAPSHOT we would be providing a version for the V-next release >> manager which could be wrong and the concern was that the proper >> checks wouldn't be done to see what the version *should* be. By making >> it 0.3.1-next-SNAPSHOT (or for your example 0.4-next-SNAPSHOT) there's >> no way the release manager would be able to release another 0.4. >> >> A better solution to all this would be for semantic versioning >> enforcement to run in the build and detect whether the version in the >> pom fits the changes to the code since the previous release. This is >> the long-term (hopefully medium-term) goal. But we need to do some >> work to get this in place - either with bnd/maven-bundle-plugin (if >> that's possible) or a maven plugin based on the new Aries 'versioning' >> module. Even with this, though we would need to figure out what the >> version of the trunk should be immediately after the release, when >> there are no changes (yet). >> >>> >>> I didn't understand (a) even while the release was pending. >>> >>> I'd guess this might have something to do with the policy of choosing the >>> version number as part of the release process. Maybe this policy could be >>> revisited. What would be wrong with having the trunk version be the >>> <expected next release version>-SNAPSHOT and changing the >>> <expected-next-release-version> up or down as changes accumulate and/or are >>> removed? >> >> The concern was, moving the release number up as changes accumulate >> wouldn't be done and we would make releases that weren't semantically >> versioned correctly. Having a semantic-version-enforcer plugin would >> mostly solve this (except it would really syntactic version checking). >> >>> >>> I think adopting an aries-only versioning scheme may confuse a lot of >>> potential consumers. >> >> Are you suggesting the semantic versioning scheme is going to confuse >> consumers? Or just the use of -next-SNAPSHOT? There's a lot of good >> arguments for using a semantic versioning scheme. I don't want to >> confuse consumers, but equally, it's confusing to have the version at >> 0.3.2-SNAPSHOT when there's no way of knowing that's going to be the >> next version. >> >> I still think using <latest-release>-next-SNAPSHOT (if it works) as >> the initial version to use in the trunk after a release. Then use a >> semantic verison enforcer to ensure the version is moved on when >> changes happen. So for example, 0.3.1-next-SNAPSHOT -- fix made --> >> 0.3.2-SNAPSHOT -- function added --> 0.4-SNAPSHOT >> >>> >>> thanks >>> david jencks >>> >>> On Nov 8, 2011, at 10:51 AM, Jeremy Hughes wrote: >>> >>>> Hi, last month I posted this [1]: >>>> >>>>> OK, so I'm replying to my own email :-) A sticking point is the >>>>> version in the pom during the staging of releases and after the >>>>> release. a) we don't want to choose the next version of a module while >>>>> releasing the current one. b) the version needs to be >>>>> something-SNAPSHOT to keep maven happy. c) it can't be >>>>> currentrelease-SNAPSHOT because in maven that has the semantics of >>>>> being a build leading up to the currentrelease. >>>>> >>>>> So, as a suggestion, during the release process, move the trunk to >>>>> currentrelease-next-SNAPSHOT ... e.g. we're releasing 0.4, so after >>>>> the staging is complete, trunk will be 0.4-next-SNAPSHOT. I think that >>>>> solves all three constraints above. >>>> >>>> I'm currently reintegrating the release branch into trunk, so the >>>> versions of the modules in trunk will change to become <latest >>>> release>-next-SNAPSHOT. Rather than have a mixture of modules in the >>>> form <next release>-SNAPSHOT and <latest release>-next-SNAPSHOT I'm >>>> planning on changing the versions used in the rest of trunk (those >>>> that weren't just released). Before I do this though, does anyone see >>>> any problem with this. One oddity will be modules that haven't yet had >>>> a release - they'll be changed to 0.0.0-next-SNAPSHOT. >>>> >>>> WDYT? >>>> >>>> Thanks, >>>> Jeremy >>>> >>>> [1] >>>> http://mail-archives.apache.org/mod_mbox/aries-dev/201110.mbox/%3CCAKbW_r5pnf9gFvkJ7Oon7JbX8qeP7KOt6reFkXbPwTS%3DjvweMw%40mail.gmail.com%3E >>> >>> > >
