Interesting I see the point of non-reproducibility; however, if one follows a semantic versioning scheme then 1.2.2 and 1.2.3 are both completely compatible. Even better between 1.2.2.1 and 1.2.2.2, which is the case where the 4th digit is just an RC counter
But back to your point, so the recommended way is to do an RC 1.2.2.2 of the dependency and then update the 50 poms that have it as a dependency to use the new 1.2.2.2 instead of 1.2.2.1? sometimes, like in my case, the dependency is developed by another team so it's not even easy to know when a new RC has been created. And because the changing digit is just an RC counter, then it will change relatively often right before a release Then add to all that a CI server, which increases the requirement of a non-interactive scheme. Any guidelines for this (seemingly) common scenario? Alejandro Endo | Software Designer/Concepteur de logiciels Miranda Technologies | Tel: (514) 333-1772 Ext: 3789 3499 Douglas-B.-Floreani, Montréal, QC H4S 2C6 Canada Miranda Technologies is a brand of Belden Inc. From: Stephen Connolly <stephen.alan.conno...@gmail.com> To: Maven Users List <users@maven.apache.org>, Date: 16/05/2013 06:20 AM Subject: Re: RC and SNAPSHOT dependencies Aside: in my experience using version ranges in released poms is a serious anti-pattern. I can just about accept arguments for their use in development poms, but at release time it is my experience that they should be pinned to the specific version that the release is performed with (otherwise the release build is not reproducible) Dependency version ranges are a seductive siren, one that Maven listened to, and I think in retrospect it was a mistake to listen to that siren. On 15 May 2013 21:38, <alejandro.e...@miranda.com> wrote: > > > Is there a maven way to have an artifact of version SNAPSHOT with > dependencies of type SNAPSHOT that when doing a release via the > maven-release-plugin can be changed to non-snapshot dependencies, in > particular actually a **range** of RCs? > > what I want is a POM like this > > ... > <version>1.0.0-SNAPSHOT</version> > > ... > <dependency> > <groupId>...</groupId> > <artifactId>...</artifactId> > <version>2.1.0-SNAPSHOT</version> > </dependency> > > that when doing a release build with the maven-release-plugin becomes > > <version>1.0.0.0</version> <!-- this I control by hand when running > m-release-p --> > <dependency> > <groupId>...</groupId> > <artifactId>...</artifactId> > <version>[2.1.0.0, 2.1.0.999]</version> > </dependency> > > So the versioning scheme i'm following is that all snapshot builds of this > artifact depend on a snapshot dependency version (2.1.0-SNAPSHOT in my > example) but that RCs contain a fourth digit that is just an RC counter. > All this because i can't redeploy a single RC 2.1.0 and the numerical > quality of a fourth digit seems simpler than an "RC" qualifier which is > treated lexicographically in a range and which causes a -SNAPSHOT to be > deemed newer than an -RC > > What I'm trying to avoid is having to update all <dependency> tags to a > particular RC count every time there is a new RC of the 2.1.0 dependency. > This is why i use a range for all the RCs > > At a higher level, what I'm trying to do is simply to have snapshots depend > on snapshots and RCs depend on the latest RC within a branch, not just the > newest RC. Feel free to suggest a completely different (correct?) way to do > this > > 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.
