[DISCUSS] Module versions in trunk

[Jeremy Hughes <hu...@apache.org>]

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

Re: [DISCUSS] Module versions in trunk

[Jeremy Hughes <hu...@apache.org>]

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 <fm...@gmail.com> 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 <da...@yahoo.com> 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 <da...@yahoo.com> 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
>>>
>>>
>
>

Re: [DISCUSS] Module versions in trunk

[David Jencks <da...@yahoo.com>]

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 <da...@yahoo.com> 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
>> 
>> 

Re: [DISCUSS] Module versions in trunk

[Jeremy Hughes <hu...@apache.org>]

On 8 November 2011 20:01, David Jencks <da...@yahoo.com> 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
>
>

Re: [DISCUSS] Module versions in trunk

[David Jencks <da...@yahoo.com>]

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?

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? 

I think adopting an aries-only versioning scheme may confuse a lot of potential consumers.

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