Yes, absolutely it forces to move to the next version. I think a build number (for example automatically increasing or last digit matching the revision number in the version control system) is a relic from the time where properly versioning something was too difficult. Maven makes versioning easy. Maven manages the version numbers, so it needs to know all of the version components. In one of our projects, we have a very similar versioning scheme (major.minor.patch.build-number), but when we make a new main (QA) release, we'll just release it as x.y.0.0, then crank up automatic releases (x.y.0.1, x.y.0.2 etc.) as needed. If we need a bug-fix release (x.y.1.0), we create a branch from the tag, again with the help of release plugin. If you don't want to make official releases for each QA build, you can just use uniquely versioned snapshots.
Kalle On Mon, Jun 9, 2008 at 9:34 AM, EJ Ciramella <[EMAIL PROTECTED]> wrote: > 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] > >
