Unless, of course, the problem wasn't the code but that it was packaged incorrectly. In this case, I am only correcting the packaging, not the release.
-----Original Message----- From: Vitaliy Geraymovych [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 11:28 To: Maven Users List Subject: Re: Release builds and continuous integration My understanding is that if you are making changes to official release you really should increment the version (and tag it in CVS/SVN). Vitaliy On 10/3/05, Allison, Bob <[EMAIL PROTECTED]> wrote: > I really dislike your suggestion for item 1, since that implies that if > I discover a problem with the release build and have to rebuild it, I > have to remember to manually remove the release build from the > repository first. > > -----Original Message----- > From: David Jackman [mailto:[EMAIL PROTECTED] > Sent: Monday, October 03, 2005 10:54 > To: Maven Users List > Subject: Release builds and continuous integration > > > I've just started to get my hands wet with Maven 2, and I must say I > like what I'm seeing. Just about every headache we currently have with > Maven 1 is addressed to some extent by Maven 2. > > One problem we were having around Maven 1 that I'm not too sure about > for the future is the issue of "official" release (non-snapshot) builds > and continuous build tools (like CruiseControl). When releasing a Maven > project, the goal is to have as much confidence as possible (a > guarantee, hopefully) that the release build in the Maven repository > exactly matches the code that was tagged in source control for that > project. The following is a list of potential risks we have in our > current Maven 1 process that I'm hoping Maven 2 can mitigate. Can > anyone respond to these? > > 1. In Maven 1, we use the scm:prepare-release goal to start the release > process. When it works (see the issues I've logged about it), this goal > changes the currentVersion to the release version, tags the code in > source control for the release, and adds a <version> element indicating > the release version and its corresponding SCM tag. Sometimes, the > developer doing the release will want to build & deploy the official > release build himself to be sure it matches the tagged code. When the > release build is complete, he will (should) change the currentVersion to > the next snapshot version. > However, since we use a continuous build tool, there is a risk that > between the time the developer deploys the release build and checks in > the project.xml with the next snapshot version, the automated build will > do its own build using the release version and deploy over the top of > the "official" release build. There are steps the developer can take to > mitigate this, but it would be better if Maven helped out more. For > this scenario, the easiest solution would be for Maven to fail the > deploy for a release (non-snapshot) version if there is already an > artifact in the destination repository of the same name. Is this > possible? > > 2. Ideally, we'd prefer that the build machine (running the continuous > build tool) do the official release builds because it's more of a > controlled build environment. However, there are two risks here. First > is that the build tool will do more than one build of the release > version (before the currentVersion is changed to the next snapshot > version). The solution in the previous paragraph would help here as > well. The second risk is that someone else will check in a code change > before the build tool does the official release build, so the release > artifact does not match the code tagged for that release in source > control. Any ideas on how to address this problem? > One approach would be to have some plugin on the continuous build > machine that checks the projects before starting the build (but after > the latest code is obtained from SCM) to see if any projects have a > release (non-snapshot) currentVersion value. If so, this plugin would > use the <version> element for this version to make sure that the code > that will be built matches the tag for this release. Then it lets the > build go on. Would this be hard in Maven 2? Even better would be to > have a plugin that, once the release build is finished and deployed, > would change the currentVersion to the next snapshot version. > > What do you think? Has anyone else had to deal with this risks? Is > there a better approach to solve these problems that I'm not seeing? > > Thanks, > ..David.. > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
