You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by kroe <ke...@surveysampling.com> on 2008/08/27 17:02:58 UTC
Version Numbers with Scrum
We have recently switched to the scrum development process, and are forced
to rethink our maven versioning scheme. There will be multiple scrum teams
working with the same code-base. Each team will aim to have a release each
sprint, but occasionally a release will be planned for one sprint but pushed
back to the next.
Can anyone reccomend a maven versioning scheme that fits the scrum
development process well?
The first scheme that comes to mind is <Development Group
Identifier>.<Sprint Number>.<Candidate Number>.
Development Group Identifier: Identifies which scrum team owns the version.
Sprint number: Specifies which sprint the code is intended to be released
in. This may change if a release gets postponed, for instance a project may
be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so the
release version would be 1.4.0.
Candidate number: Each release to QA has a distinct candidate number. If QA
rejects the candidate then development works on the next candidate
(incrementing number), and releases this candidate to QA when it is ready.
This will give QA a permanent version number for each artifact they perform
a test cycle on.
Thanks for the input
--
View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version Numbers with Scrum
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Wed, Aug 27, 2008 at 11:02 AM, kroe <ke...@surveysampling.com> wrote:
> We have recently switched to the scrum development process, and are forced
> to rethink our maven versioning scheme. There will be multiple scrum teams
> working with the same code-base. Each team will aim to have a release each
> sprint, but occasionally a release will be planned for one sprint but
> pushed
> back to the next.
>
> Can anyone reccomend a maven versioning scheme that fits the scrum
> development process well?
In your proposal, would the development group identifier be numeric? That'd
be awkward, as it would imply that higher-identiers supercede lower ones, in
terms of a normal versioning number scheme.
If I couldn't avoid this kind of structure altogether (which is my first
reaction), I'd be inclined to push most of this information pretty far down
in the version identifier. I might end up using something like <release
major>.<release minor>.<release patch>-<dev group>.<sprint>.<candidate>.
So during the development of product release 1.0, you might be working on
1.0.0-MikesTeam.5-SNAPSHOT, and then put out 1.0.0-MikesTeam.5.1 to QA,
followed by 1.0.0-MikesTeam.5.2 if they reject it. I don't have any sense
of how you're planning on integrating the work from each team into a comon
stream, so I won't talk about that. But at least that way the higher
version numbers are still meaningful and useful. I'd stay away from numeric
representation of the teams to avoid putting some kind of numeric priority
to them that wasn't intended.
- Geoffrey
--
Geoffrey Wiseman
RE: Version Numbers with Scrum
Posted by kroe <ke...@surveysampling.com>.
We have separate working branches for each team. After a version is released
it is merged into the trunk. There is only one current production version
of each application. Our software is developed for internal use so no need
to maintain previous versions.
P'Simer, Dana (Matrix) wrote:
>
> We are doing something similar. I am guessing that you are putting the
> various sprint teams on separate branches and merging them in when you
> need to create a combined release. Or are you actually producing
> alternative versions of you product?
>
> If the former, then the first blush response might be to use classifiers
> but that did not work for us because we have several artifacts in each
> component and are already using classifiers for other purposes.
> Classifiers also do not allow for the isolation of POM changes.
>
> So we decided to use a versioning scheme where each branch had their own
> "moniker" added to the version number.
>
> Our project is currently at 4.12.0-SNAPSHOT. I am working on a project
> with the initials "tc" so my branch is on 4.12.0-tc-SNAPSHOT.
>
> When we merge the branches together they become 4.12.0-SNAPSHOT and then
> we release it as 4.12.0.
>
> This allows the development and QA for each project to proceed
> independently.
>
> When we release, we merge everything back to the trunk, deploy everything
> to an integration environment and smoke test the applications. Then we
> move the code to a nearly production like environment for final QA.
>
> I do not like the idea of using numbers to represent concepts. It makes
> the version numbers hard to understand and there is nothing in Maven that
> says your versions have to contain only numbers.
>
>
> -----Original Message-----
> From: kroe [mailto:ken@surveysampling.com]
> Sent: Wed 8/27/2008 11:02 AM
> To: users@maven.apache.org
> Subject: Version Numbers with Scrum
>
>
> We have recently switched to the scrum development process, and are
> forced
> to rethink our maven versioning scheme. There will be multiple scrum
> teams
> working with the same code-base. Each team will aim to have a release
> each
> sprint, but occasionally a release will be planned for one sprint but
> pushed
> back to the next.
>
> Can anyone reccomend a maven versioning scheme that fits the scrum
> development process well?
>
> The first scheme that comes to mind is <Development Group
> Identifier>.<Sprint Number>.<Candidate Number>.
>
> Development Group Identifier: Identifies which scrum team owns the
> version.
>
> Sprint number: Specifies which sprint the code is intended to be released
> in. This may change if a release gets postponed, for instance a project
> may
> be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so
> the
> release version would be 1.4.0.
>
> Candidate number: Each release to QA has a distinct candidate number. If
> QA
> rejects the candidate then development works on the next candidate
> (incrementing number), and releases this candidate to QA when it is ready.
> This will give QA a permanent version number for each artifact they
> perform
> a test cycle on.
>
> Thanks for the input
> --
> View this message in context:
> http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>
--
View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19183363.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Version Numbers with Scrum
Posted by "P'Simer, Dana (Matrix)" <Da...@ihg.com>.
We are doing something similar. I am guessing that you are putting the various sprint teams on separate branches and merging them in when you need to create a combined release. Or are you actually producing alternative versions of you product?
If the former, then the first blush response might be to use classifiers but that did not work for us because we have several artifacts in each component and are already using classifiers for other purposes. Classifiers also do not allow for the isolation of POM changes.
So we decided to use a versioning scheme where each branch had their own "moniker" added to the version number.
Our project is currently at 4.12.0-SNAPSHOT. I am working on a project with the initials "tc" so my branch is on 4.12.0-tc-SNAPSHOT.
When we merge the branches together they become 4.12.0-SNAPSHOT and then we release it as 4.12.0.
This allows the development and QA for each project to proceed independently.
When we release, we merge everything back to the trunk, deploy everything to an integration environment and smoke test the applications. Then we move the code to a nearly production like environment for final QA.
I do not like the idea of using numbers to represent concepts. It makes the version numbers hard to understand and there is nothing in Maven that says your versions have to contain only numbers.
-----Original Message-----
From: kroe [mailto:ken@surveysampling.com]
Sent: Wed 8/27/2008 11:02 AM
To: users@maven.apache.org
Subject: Version Numbers with Scrum
We have recently switched to the scrum development process, and are forced
to rethink our maven versioning scheme. There will be multiple scrum teams
working with the same code-base. Each team will aim to have a release each
sprint, but occasionally a release will be planned for one sprint but pushed
back to the next.
Can anyone reccomend a maven versioning scheme that fits the scrum
development process well?
The first scheme that comes to mind is <Development Group
Identifier>.<Sprint Number>.<Candidate Number>.
Development Group Identifier: Identifies which scrum team owns the version.
Sprint number: Specifies which sprint the code is intended to be released
in. This may change if a release gets postponed, for instance a project may
be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so the
release version would be 1.4.0.
Candidate number: Each release to QA has a distinct candidate number. If QA
rejects the candidate then development works on the next candidate
(incrementing number), and releases this candidate to QA when it is ready.
This will give QA a permanent version number for each artifact they perform
a test cycle on.
Thanks for the input
--
View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Version Numbers with Scrum
Posted by David Roussel <na...@diroussel.xsmail.com>.
I the past I've tried to separate the technical versions from the planning
versions. Some projects do this with code names, but we did with release
numbers. The CI system gave us build numbers, we didn't know in advance
which build would become the release, esp weeks in advance. So when people
ask which version is going to contain feature X, or bug fix Y, then we tell
them the planned release number (or code name), and then we have a build and
we release it, we bind the release number to the build number.
Once the project had been running for a long time the separation between the
two version numbers wasn't so tight, and it didn't matter as we were much
better about planning releases as there was less change.
David
--
View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19250282.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org