The one curiosity about this is it forces the user to move to the next version (unless I'm missing something).
As I said earlier, when we close in on a release, we build more frequently then we did during development. When we run the release plugin, it moves the version of the pom from 1.0-SNAPSHOT to 1.0. Typically, our build numbers are four digits and we increment the final digit to reflect how many times something has been built. Batch mode seems to force moving from a snapshot to a fully fledged release number. Is there a way to avoid this or am I circumventing something I shouldn't by doing this? -----Original Message----- From: Kalle Korhonen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2008 6:29 PM To: Maven Users List Subject: Re: Moving from snapshot to release - how do _you_ do it Now I feel like I'm probably missing something, but you do want to give some kind of command to release the project, don't you? Releasing a properly maintained build with the release plugin doesn't require "command line intervention", it can be just another build target on your continuous integration system (in fact Continuum even has a button for it). If you run the release:prepare with --batch-mode, it'll use the default values for version and tag ( http://maven.apache.org/plugins/maven-release-plugin/usage.html). But it really depends on your project what the best release strategy is. We have one project producing a low-level library where releasing is literally just one push of button, and a few other ones consisting of multiple sub-modules, where the release tag is created days before actually performing the release, allowing people time to examine the tag and run longer manual tests on it. All of the projects are using the release plugin and the time spent on making release process more automated and smoother with it is well spent in my opinion. Kalle On Fri, Jun 6, 2008 at 2:40 PM, EJ Ciramella <[EMAIL PROTECTED]> wrote: > It works, but in our case, we tend to spin multiple builds hoping to > release each candidate (as many as we can squeeze into a day sometimes). > > What I don't want to do is move from a highly automated process to one that > requires command line intervention. > > > -----Original Message----- > From: Geoffrey Wiseman [mailto:[EMAIL PROTECTED] > Sent: Fri 6/6/2008 5:14 PM > To: Maven Users List > Subject: Re: Moving from snapshot to release - how do _you_ do it > > On Fri, Jun 6, 2008 at 12:34 PM, EJ Ciramella <[EMAIL PROTECTED]> > wrote: > > > When it comes down to release time, how are people migrating from > > snapshots to releases? Our release numbering scheme has always been in > > a major.minor.patch.build-number format. Toward the end of a release > > cycle, we build multiple times. What I don't want to have happen is > > needing release engineering to spin each and every build by hand when > > it's deemed a releasable version (I'm very happy having CC spin up our > > other deployable units). Plus, it gives QA the ability to say, "Found > > in build 1.1.0.27" and "Fixed in build 1.1.0.32". Versus "Found in > > build 1.0-SNAPSHOT" and "Fixed in build <sometimestamp>". Are people > > building/testing/etc by hand in release engineering? > > > > I'd love to know what people are truly doing. > > > > I feel as if I'm missing something in this question, so if I'm answering > the > wrong thing, lemme know, but basically we use version-SNAPSHOT for > development, then release using the maven release plugin, which'll deploy a > non-snapshot version and then move us up to the next version in line. > > e.g, if I'm on myproject at version 1.1-SNAPSHOT, I'll do a release:prepare > (dry run), then a release:clean and release:prepare (not-dry run) and a > release:perform. > > This creates and deploys myproject-1.1 (package, sources and pom), and > leaves me at 1.2-SNAPSHOT, unless I specify otherwise (like 2.0-SNAPSHOT). > > Is that the kind of answer you're looking for? > > - Geoffrey > > -- > Geoffrey Wiseman > > > --------------------------------------------------------------------- > 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]
