I think you have a different understanding of what a SNAPSHOT is, than maven has.
For maven, a SNAPSHOT version has no really defined state in the SCM but only any current checkout which is NOT reproducable. So, it imho does _not_ make sense to perform user testing with this version. Typically a version in the pom is not only 2 digits, but 3 or 4 and also may contain textual parts. So e.g we have a plat.core.backend-3.9.47-branch-12-SNAPSHOT which will finally be released as plat.core.backend-3.9.47-branch-12 and then automatically incremented to plat.core.backend-3.9.47-branch-13-SNAPSHOT for further development. You can also use another text than 'branch' e.g. 'rc' yourproject-2.4-rc.2-SNAPSHOT So you do not 'waste' too much versions if you don't like. A bit off topic: I had the same problems in understanding the 'maven world' back in the early millenium when Sigi Goeschl and Martin Pöschl first convinced me with maven. It is mostly about not doing all things by copy and paste with ant, but to use already working best-practice approaches. You can simulate (almost) all the behaviour of ant with maven (even easier with maven2 then it was with maven1), but it is much more pleasant to do it the maven way. Or let's say it this way: The only important things are a) what is your problem b) what is the goal c) how the easiest/cheapest/most maintainable way And sometimes it c) is easier to achieve by changing the process itself. LieGrü, strub --- EJ Ciramella <[EMAIL PROTECTED]> schrieb am Mo, 9.6.2008: > Von: EJ Ciramella <[EMAIL PROTECTED]> > Betreff: RE: Moving from snapshot to release - how do _you_ do it > An: "Maven Users List" <[email protected]> > Datum: Montag, 9. Juni 2008, 18:34 > 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] __________________________________________________________ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
