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