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:[EMAIL PROTECTED] Sent: Wed 8/27/2008 11:02 AM To: [email protected] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
