I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however...
IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!). If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness. Or to put it another way Staging with any human intervention is evil. Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now). Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) Z is released into a stage The library is picked up in product X (inside say another RPM) QC start testing Z. QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped QC finish testing Z from the stage and then promote it as its good. The Y developers re-spin 1.2.3... Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo. The build Z is unreproducible - this is the worst possible situation to be in, Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM. Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible. /James > -----Original Message----- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: 20 January 2014 19:40 > To: Maven Users List > Subject: Re: versions maven plugin > > Consider staging support on your repo manager > > On Monday, 20 January 2014, <alejandro.e...@miranda.com> wrote: > > > I didn't. QA is not happy about rebuilding the system once it's been > > approved so we have to release the RC as approved. > > > > So all our versions are always RC-X-SNAPSHOT or RC-X > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > > > From: Stephen Connolly <stephen.alan.conno...@gmail.com > <javascript:;>> > > To: Maven Users List <users@maven.apache.org <javascript:;>>, > > Date: 2014-01-20 13:50 > > Subject: Re: versions maven plugin > > > > > > > > How did you turn your RC into a released version? (I would do it with > > the release plugin and just verify the SCM changelog is unchanged) > > > > On Monday, 20 January 2014, <alejandro.e...@miranda.com > > <javascript:;>> > > wrote: > > > > > Thank you Stephen. Are there any other ways to stabilize my > > > dependencies then? > > > > > > i have > 300 poms all depending on the released+1 development version. > > > This must be a common use-case when using RCs, no? you increase all > > > your versions to your next RC-2-SNAPSHOT as soon as you create your > > > RC-1, but if that RC-1 happens to be released, then all your poms > > > will be > > depending > > > on the SNAPSHOT of an RC-2 that will never be made so you have to > > > "downgrade" your dependency versions > > > > > > Am I doing something out of the ordinary here? > > > > > > > > > > > > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > > > > > From: Stephen Connolly <stephen.alan.conno...@gmail.com > <javascript:;><javascript: > > ;>> > > > To: Maven Users List <users@maven.apache.org > <javascript:;><javascript:;>>, > > > Date: 2014-01-20 12:34 > > > Subject: Re: versions maven plugin > > > > > > > > > > > > v-m-p does not roll back version numbers > > > > > > > > > On 20 January 2014 16:59, <alejandro.e...@miranda.com > > > <javascript:;><javascript:;>> > > > wrote: > > > > > > > Not sure if this is the right list for codehaus plugins. If not I > > > > apologize > > > > > > > > I have a pom with this > > > > > > > > <dependencies> > > > > <dependency> > > > > <groupId>foo.blah</groupId> > > > > <artifactId>bar</artifactId> > > > > <version>1.2.0-RC-7-SNAPSHOT</version> > > > > </dependency> > > > > </dependencies> > > > > > > > > I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT > > > > with > > > the > > > > version we actually released of the code, which is 1.2.0-RC-6. > > > > Looking > > > at > > > > the available mojos, it seems like versions:use-latest-releases is > > > > the right one to use. In the matrix here it says that this goal > > > > will > > modify > > > > -SNAPSHOT dependencies. Well, it doesn't. If i instead set the > > > > version > > > to > > > > 1.2.0-RC-3 (no snapshot), the mojo does update the dependency to > > > > 1.2.0-RC-6 so I don't know if this is just the documentation being > > > wrong. > > > > I also tried use-latest-versions without success > > > > > > > > Any idea how to do this? I just want to change the dependencies > > > > (which > > > are > > > > currently SNAPSHOT due to the m-release-p) to the latest released > > > versions > > > > > > > > Thank you, > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > DISCLAIMER: > > > > Privileged and/or Confidential information may be contained in > > > > this message. If you are not the addressee of this message, you > > > > may not copy, use or deliver this message to anyone. In such > > > > event, you should destroy the message and kindly notify the sender > > > > by reply e-mail. It is understood that opinions or conclusions > > > > that do not relate to the official business of the company are > > > > neither given nor endorsed by the company. > > > > Thank You. > > > > > > > > > > > > > DISCLAIMER: > > > Privileged and/or Confidential information may be contained in this > > > message. If you are not the addressee of this message, you may not > > > copy, use or deliver this message to anyone. In such event, you > > > should destroy the message and kindly notify the sender by reply > > > e-mail. It is understood that opinions or conclusions that do not > > > relate to the official business of the company are neither given nor > > > endorsed by the company. > > > Thank You. > > > > > > > > > -- > > Sent from my phone > > > > > > DISCLAIMER: > > Privileged and/or Confidential information may be contained in this > > message. If you are not the addressee of this message, you may not > > copy, use or deliver this message to anyone. In such event, you should > > destroy the message and kindly notify the sender by reply e-mail. It > > is understood that opinions or conclusions that do not relate to the > > official business of the company are neither given nor endorsed by the > > company. > > Thank You. > > > > > -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
