maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro.E...@miranda.com
Subject Re: RC and SNAPSHOT dependencies
Date Thu, 16 May 2013 14:46:33 GMT

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.connolly@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.Endo@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.


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message