very interesting Brian, thanks for sharing. May I ask how you manage your internal build increment and its reset? It seems it's not the SCM build number.
Does your system allow for modification of a build-tags? Or do you rebuild from the trunk? But in the latter case you have additional code and may not have been expected in the release. Brian E Fox wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Release-cycle---Maven-release-plugin-usability-tp16296781s177p16322614.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]
