Please note I've added a new goal release:stage to cover such a use case : prepare the release, stage it to a test / demo repository. When something is wrong, simply rollback and delete/rename the tag in SVN.
2008/6/10 Kalle Korhonen <[EMAIL PROTECTED]>: > 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] > > > > >
