aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [DISCUSS] Module versions in trunk
Date Wed, 09 Nov 2011 17:23:05 GMT
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 <> 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
> 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]

View raw message