In your situation, whenever you think you are ready for a release, I'd just run release:prepare to create the tag, but not run release:perform immediately. Then check out the tag, and run your manual regression etc. testing suites against it. If minor things - like configuration or versions are wrong, fix directly in the tag, otherwise just abandon the tag and never release that version, fix the build and and release:prepare a new one - you got unlimited number of versions at your disposal. Once you are confident the tag's good, only then release:perform or just deploy from the tag. Basically you always consider a tag a normally versioned release candidate until you publish it into your distribution repository. This is what we do in one projects and generally works well. After all, this is why the release is a two-step process.
Kalle On 12/13/07, Eric Minick <[EMAIL PROTECTED]> wrote: > > Thanks Marco, > > I also tend to agree here as well and I think this would be a no-brainier > if > I was going to production quarterly. This particular project has minor > updates going into production every week or three. That's border-line > insane, but that matches the business needs. I've been at a number of > organizations that work the same way. > > My concern is that branch explosion could be difficult to manage from a CI > perspective as well as for developers. > > I again find myself asking for "best practices" without giving all the > details. My apologies. Best practices always change a bit as you face > different problems. > > -- Eric > > On 12/13/07, Beelen, M. - SPLXL <[EMAIL PROTECTED]> wrote: > > > > Eric, > > > > When I read your email I think it's more an issue for source code > > management and versioning, then that it should be for maven. > > > > If you start the process of releasing a module, you could create a > > branch for that version and then release some beta or milestones (M1, > > M2, M3, ....., M10) from that branch and send it to QA. If QA approves a > > certain milestone, you could check it out and adjusted the > > version-number to remove the milestone identifier and release the actual > > version. > > > > Changes to mainline code should be performed on the trunk so they won't > > get in the way of you release and QA proces. Upon your release, you > > should merge the changes from the branch to the trunk and continue to > > work on the next release. > > > > With kind regards, > > Marco > > > > > > > > > > > > > > -----Original Message----- > > From: Eric Minick [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 12, 2007 11:25 PM > > To: users@maven.apache.org > > Subject: Pre-release Testing Best Practices? > > > > I'm looking at doing some releases using the maven release plugin. Our > > environment is a set of pretty typical in house development projects for > > some web-apps. So we have things like dev, qa and production > > environments for deployment and frequent releases. > > > > We don't want to cut a release before doing QA on it. So an ideal > > scenario is to put a snapshot build into QA, and get it approved. Once > > approved, we would want to release that code, verify that dependency > > changes didn't break things with regression tests, then move on to > > staging and production. > > > > A natural concern here is that there are likely more changes to the > > mainline code base that come in during testing and we would not want to > > release those. Getting the code that went into the tested build out of > > source control at release time is not a problem though. > > > > I have two questions: > > > > 1) Are there common \ recommended strategies for dealing with this type > > of scenerio? > > 2) If I just pull the old code out and run a release, is the SVN label > > (copy) command a local copy (which would only include the files in my > > release space) or a remote copy (which would include my newly checked in > > pom as well as any changes committed since we went to QA)? > > > > Thanks, > > > > Eric > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ********************************************************************** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you have > > received this e-mail by error, please notify the sender immediately > > by return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > and/or its employees shall not be liable for the incorrect or > > incomplete transmission of this e-mail or any attachments, nor > > responsible for any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > ********************************************************************** > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
