Here's how I deal with it: Each build that goes to QA is in fact a mini release. The presumption is that any release could actually go to the customer (without rebuilding to promite). We use x.y.z-build as our versioning, but refer to a customer release simply using the x.y.z number. Each internal build increments the build number, but at soon as it goes outside the company, the x.y.z is incremented and build goes back to 0. To handle the tagging, we expanded on the svn concept a bit. We have build-tags and release-tags instead of just /tags. Every build goes to build-tags automatically. When a release occurs, we move the tag to release tags and delete the other build tags.
-----Original Message----- From: nodje [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 11:05 PM To: [email protected] Subject: Re: Release cycle - Maven release plugin usability Good point. I guess I was expecting something "automatic" since only a production release would need an increment in the version. I should trust the developer won't mess up with that :) Trying to look for future direction on the Maven Release plugin, I just noticed the release:branch goal! That's what I need, I'll explore further before opening my mouth again... Sorry about that! Stephen Connolly-2 wrote: > > There is nothing that says that a version number has to be a number! > > I would do the TEST release as > 1.2.3-SNAPSHOT -> 1.2.3-TEST-1 > If you want to do multiple test releases (i.e. there was a big fubar with > 1.2.3-TEST-1, so we're going again then you have 1.2.3-TEST-2) > > When you are finally ready to roll you just go > > 1.2.3-TEST-x -> 1.2.3 > > On Wed, Mar 26, 2008 at 7:36 AM, nodje <[EMAIL PROTECTED]> wrote: > >> >> I'm not 100% sure it's the right forum to ask question about releasing. >> But since it's supported by the release plugin and since I'm trying to >> implement my cycle with it, I'm gonna give it a shot! >> >> I'm trying to use the release plugin cycle to support our applications >> staging needs. >> >> While I now have automatically configured WARs for each environement >> thanks >> to the Resources and War plugin, I still cannot have them deployed in a >> consistent way regarding the version numbering and the tagging of the >> SCM. >> >> In our environment, the staging happens this way: a TEST release is first >> produced. This release will be amended with bug fix and then promoted to >> a >> PRODUCTION release. >> >> When trying to implement that with Maven release plugin, I first have an >> issue with the numbering since the TEST and PROD release must in fact >> have >> the same version (but not the same name). This I can easily overcome by >> entering the current version in the release:prepare phase. >> But I'm wondering what's the reasoning behind the release plugin way. >> >> The second point is that we have to modify the TEST release before >> promoting >> it to PROD. But since it has been tagged in the SCM, it's not supposed to >> be >> modified (at least the way I understand "tagging" a version). >> >> Again, I'm trying to understand the reasoning behind the release plugin >> functionning. >> How can it accomodate a staging environment like mine (DEV->TEST->PROD)? >> Or >> how can I adapt my environment to the Release plugin way. >> Shouldn't it propose to branch instead of tag? >> >> thanks for any feedback, I'm a little bit lost here :) >> >> --nodje >> -- >> View this message in context: >> http://www.nabble.com/Release-cycle---Maven-release-plugin-usability-tp1 6296781s177p16296781.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/Release-cycle---Maven-release-plugin-usability-tp1 6296781s177p16321347.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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
