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:[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] > > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
