I think you should re-read the release plugin documentation ( http://maven.apache.org/plugins/maven-release-plugin/, the examples give you the steps the plugin does) and then try it out on a small project. release:prepare changes the version numbers, creates the tag and then prepares the trunk for the next iteration (changing the versions to the next development SNAPSHOT). Related to your last note, that's why the release is in two pieces: you can create a tag with all version numbers changed etc. and then examine the tag when everything is ready to go. If the tag's bad, you can simply abandon the release.
Kalle On Mon, Jun 9, 2008 at 2:36 PM, EJ Ciramella <[EMAIL PROTECTED]> wrote: > Here's another view that many have here, what exactly does running the > release plugin buy us? > > So far, it doesn't seem to fit the bill (and I can't just plant the anchor > and spin the queen mary around it - ie: change process), why NOT just skip > it and use deploy:deploy or deploy:deploy-file (which has more granular > controls)? > > A different set of modules we're building here require the developer to let > CC build (which also tests) the lower level modules first in order to get a > build number to insert into modules that consume these (and so on and so > on). In one case, we have three "hops" so to speak. Locally, everyone can > just use snapshots and build at will. But if you want the final webApp to > pick up your changes, you MUST supply a valid version. The only hurdle we > had with this is people had to know how to effectively use snapshots locally > (which many didn't understand). The flip side to this coin (with the new > project where we're evaluating the release plugin) is knowing when to take > snapshots from the internal repo. > > Thoughts? > > -----Original Message----- > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > Sent: Monday, June 09, 2008 4:00 PM > To: Maven Users List > Subject: RE: Moving from snapshot to release - how do _you_ do it > > I agree very much with your final assessment. > > Sometimes when we work ourselves here into a m2 pigeon hole, we step back > and review what we're doing and where possible, try to alter the processes > around <something>. Sometimes that's just not duable. > > I agree that snapshots shouldn't necessarily be tested by qa, but dev may > like to deploy that to a dev integration stack. > > Additionally, when I run mvn release:perform, the result is the pom (for > the module I'm releasing) changes the version from 1.0-SNAPSHOT to 1.1 (in > the simplest case). If we're planning on doing release candidate type > drops, who's in charge of the versioning, the person who checks into the > codeline? Also, because release:perform changes the version number, someone > would have to set it back to 1.1-SNAPSHOT (from 1.1) in order for mvn > release:perform to work properly, correct? > > -----Original Message----- > From: Mark Struberg [mailto:[EMAIL PROTECTED] > Sent: Monday, June 09, 2008 1:22 PM > To: Maven Users List > Subject: RE: Moving from snapshot to release - how do _you_ do it > > 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" <users@maven.apache.org> > > 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] > > > --------------------------------------------------------------------- > 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] > >
