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