You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Justin Georgeson <JG...@lgc.com> on 2016/09/23 15:11:17 UTC
RE: [EXTERNAL] Re: help with version range
Yeah, I was hoping there was something more elegant like 1.1+ or something, so I can at least move forward with that.
Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has excluded 1.2.0 from their range? If I explicitly don't want the release version why would I want the pre-release versions?
-----Original Message-----
From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On Behalf Of Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range
Hi Justin,
You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match the versions you want in practice.
Regards,
Curtis
On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> had been going well. However I wanted to start working on 1.2.0 of the
> parent, so I published a 1.2.0-alpha-1 version. And all the projects
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> want 1.2.0, and second that once I do release 1.2.0 the projects which
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> ------------------------------
> This e-mail, including any attached files, may contain confidential
> and privileged information for the sole use of the intended recipient.
> Any review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive
> information for the intended recipient), please contact the sender by
> reply e-mail and delete all copies of this message.
>
Re: [EXTERNAL] Re: help with version range
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 23 septembre 2016 18:46:36 Manfred Moser a écrit :
> Fair enough. From the purely engineering/mathematical point of view it might
> not make sense. But I dont see a way to get that changed with breaking a
> TON of other stuff.
+1
> And I am not even sure if it would be more intuitive
> instead of just being different.
+1
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
> > No, you are making an invalid assumption about what I understand! I
> > completely understand the relationship of SNAPSHOTs and other pre-release
> > artifacts and released versions.
> >
> > What I am questioning is the "engineer's approach" to version range
> > resolution without a valid use case for why Maven should consider
> > pre-released versions as within the "not including 2.0" version range
> > semantics.
> >
> >
> > -----Original Message-----
> > From: Manfred Moser [mailto:manfred@simpligility.com]
> > Sent: Friday, September 23, 2016 11:32 AM
> > To: users@maven.apache.org
> > Subject: Re: [EXTERNAL] Re: help with version range
> >
> > What you are misunderstanding is how snapshots are meant to be used.
> > 2.0-SNAPSHOT means that it is a development version working towards the
> > release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> >
> > If you mislike this you can change how you work with your own projects at
> > least. .. you can just call your snapshot version 1.99-SNAPSHOT or
> > whatever
> > while developing and at releas time switch to 2.0 ..
> >
> > Manfred
> >
> > Robert Patrick wrote on 2016-09-23 08:56:
> >> This does seem non-intuitive. If I say that I want versions between
> >> 1.0
> >> and
> >> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
> >> would I ever want this to resolve to 2.0-SNAPSHOT or any other
> >> pre-release 2.0 artifact?
> >> Personally, I cannot think of a single one.
> >>
> >> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
> >> nothing related to 2.0...
> >>
> >> -----Original Message-----
> >> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> >> Sent: Friday, September 23, 2016 10:11 AM
> >> To: Maven Users List
> >> Subject: RE: [EXTERNAL] Re: help with version range
> >>
> >> Yeah, I was hoping there was something more elegant like 1.1+ or
> >> something, so I can at least move forward with that.
> >>
> >> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> >> has excluded 1.2.0 from their range? If I explicitly don't want the
> >> release version why would I want the pre-release versions?
> >>
> >> -----Original Message-----
> >> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
> >> Behalf Of Curtis Rueden
> >> Sent: Friday, September 23, 2016 9:01 AM
> >> To: Maven Users List
> >> Subject: [EXTERNAL] Re: help with version range
> >>
> >> Hi Justin,
> >>
> >> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match
> >> the versions you want in practice.
> >>
> >> Regards,
> >> Curtis
> >>
> >> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
> >>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
> >>> it had been going well. However I wanted to start working on 1.2.0 of
> >>> the parent, so I published a 1.2.0-alpha-1 version. And all the
> >>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
> >>> is in keeping with the implementation that x.y.z-(alpha|beta|…)
> >>> precedes x.y.z, but it is unintuitive to me. First in that I’ve
> >>> stated I don’t want 1.2.0, and second that once I do release 1.2.0
> >>> the projects which were receiving the alpha builds will not get
> >>> 1.2.0. I tried with both
> >>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >>>
> >>>
> >>>
> >>> *Justin Georgeson*
> >>> Landmark Cloud Platforms & DevOps - RM
> >>>
> >>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
> >>>
> >>> Follow Halliburton: *LinkedIn*
> >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
> >>> s
> >>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> >>> e
> >>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
> >>> &
> >>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
> >>> V
> >>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
> >>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> >>>
> >>> | *Facebook*
> >>>
> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
> >>> o
> >>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
> >>> r
> >>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Psk
> >>> v
> >>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uy
> >>> u
> >>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-w
> >>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> >>>
> >>> | *Twitter*
> >>>
> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
> >>> o
> >>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
> >>> r
> >>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtE
> >>> U
> >>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Qo
> >>> E
> >>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW
> >>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> >>>
> >>> | *YouTube*
> >>>
> >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
> >>> s
> >>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> >>> e
> >>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUD
> >>> K
> >>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
> >>> B
> >>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYS
> >>> K
> >>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> >>>
> >>> | *Blog*
> >>>
> >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
> >>> s
> >>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> >>> e
> >>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wu
> >>> W
> >>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjC
> >>> m
> >>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0
> >>> -
> >>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
> >>>
> >>>
> >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.so
> >>> l
> >>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxY
> >>> M
> >>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefD
> >>> D ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
> >>>
> >>>
> >>>
> >>>
> >>> ------------------------------
> >>> This e-mail, including any attached files, may contain confidential
> >>> and privileged information for the sole use of the intended recipient.
> >>> Any review, use, distribution, or disclosure by others is strictly
> >>> prohibited.
> >>> If you are not the intended recipient (or authorized to receive
> >>> information for the intended recipient), please contact the sender by
> >>> reply e-mail and delete all copies of this message.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Hervé BOUTEMY <he...@free.fr>.
I worked a lot on this in the past, and the range I found the easiest to write
is:
[1.0,2.0-a-a)
= "alpha-alpha" trick
yes, this is still a trick, but at least this better shows the intent
Regards,
Hervé
Le vendredi 23 septembre 2016 13:41:37 Robert Patrick a écrit :
> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included. I have yet to hear you or anyone
> else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now. There should be a simple way to
> achieve this that does not require me to do something like this:
>
> [1.0,1.999999999999999999999999999999999999999999999999999999999999999999999
> 999999999999999999)
>
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
> >
> > a valid use case for why Maven should consider > pre-released versions
> > as within the "not including 2.0" version > range semantics.
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/24/16 um 04:16 schrieb Justin Georgeson:
> I tried these four version ranges with the 3.4.0-SNAPSHOT from your link
>
> [1.1.min,1.1.max]
> [1.1.*]
> [1.2.min,1.2.max]
> [1.2.*]
>
> All four downloaded the expected parent POM without the warnings.
That's expected behaviour. Damn it ;-) ...
Thanks for testing.
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Justin Georgeson <JG...@lgc.com>.
I tried these four version ranges with the 3.4.0-SNAPSHOT from your link
[1.1.min,1.1.max]
[1.1.*]
[1.2.min,1.2.max]
[1.2.*]
All four downloaded the expected parent POM without the warnings.
I like the colorized output.
-----Original Message-----
From: Christian Schulte [mailto:cs@schulte.it]
Sent: Friday, September 23, 2016 8:47 PM
To: Maven Users List <us...@maven.apache.org>
Subject: Re: [EXTERNAL] Re: help with version range
Am 09/24/16 um 02:15 schrieb Justin Georgeson:
> The Aether doc shows both bounds being inclusive with the min/max form, but you have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for me with both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for me too. I'm using JDK 1.8.0_102, and my projects are pretty much all Tycho packaging-types.
>
> I am seeing these warnings
>
> [WARNING] Failed to canonicalize path
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdate
> d: The filename, direc tory name, or volume label syntax is incorrect
> Downloading:
> http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%
> 5B1.1.*%5D/master-%5B1.1.*%5D.pom [WARNING] Failed to canonicalize
> path
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdate
> d: Invalid argument [WARNING] Failed to create parent directories for
> tracking file
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
> dated
> [WARNING] Failed to build parent project for
> com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT
>
> Which are reported in the original JIRA ticket for the feature
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
> _jira_browse_MNG-2D2199&d=DQICaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2F
> ZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=leobnERpx7eIg
> IvKmjTYhgj8buTHbUXeP5uyujIxsBY&s=WtN5v0mIkuOLd0hI4m_OpYLLsyZGYi6ivI7n6
> lvH6gw&e=
>
> But it is ultimately working.
Can you please test a recent 3.4.0-SNAPSHOT and report if those messages disappear? Parent version ranges are broken in the Maven versions you mentioned.
<https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_maven-2D3.3-2Drelease-2Dstatus-2Dbuild_&d=DQICaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=leobnERpx7eIgIvKmjTYhgj8buTHbUXeP5uyujIxsBY&s=R4EYmMCVXobVq6h9SfS4A9EtWGvXSOLvTqmjLIMelbY&e= >
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
Re: [EXTERNAL] Re: help with version range
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/24/16 um 02:15 schrieb Justin Georgeson:
> The Aether doc shows both bounds being inclusive with the min/max form, but you have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for me with both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for me too. I'm using JDK 1.8.0_102, and my projects are pretty much all Tycho packaging-types.
>
> I am seeing these warnings
>
> [WARNING] Failed to canonicalize path C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: The filename, direc
> tory name, or volume label syntax is incorrect
> Downloading: http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%5B1.1.*%5D/master-%5B1.1.*%5D.pom
> [WARNING] Failed to canonicalize path C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: Invalid argument
> [WARNING] Failed to create parent directories for tracking file C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
> dated
> [WARNING] Failed to build parent project for com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT
>
> Which are reported in the original JIRA ticket for the feature
>
> https://issues.apache.org/jira/browse/MNG-2199
>
> But it is ultimately working.
Can you please test a recent 3.4.0-SNAPSHOT and report if those messages
disappear? Parent version ranges are broken in the Maven versions you
mentioned.
<https://builds.apache.org/view/All/job/maven-3.3-release-status-build/>
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Justin Georgeson <JG...@lgc.com>.
The Aether doc shows both bounds being inclusive with the min/max form, but you have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for me with both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for me too. I'm using JDK 1.8.0_102, and my projects are pretty much all Tycho packaging-types.
I am seeing these warnings
[WARNING] Failed to canonicalize path C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: The filename, direc
tory name, or volume label syntax is incorrect
Downloading: http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%5B1.1.*%5D/master-%5B1.1.*%5D.pom
[WARNING] Failed to canonicalize path C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: Invalid argument
[WARNING] Failed to create parent directories for tracking file C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
dated
[WARNING] Failed to build parent project for com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT
Which are reported in the original JIRA ticket for the feature
https://issues.apache.org/jira/browse/MNG-2199
But it is ultimately working.
-----Original Message-----
From: Robert Patrick [mailto:robert.patrick@oracle.com]
Sent: Friday, September 23, 2016 4:39 PM
To: Maven Users List <us...@maven.apache.org>
Subject: RE: [EXTERNAL] Re: help with version range
This is nice, but it doesn’t work in Maven 3.3.9...
[ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version ordering: [0.8.min,0.8.max) for project myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]
--
Robert Patrick <https://urldefense.proofpoint.com/v2/url?u=http-3A__robert.patrick-40oracle.com&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=euuADbCvIIw3JpW95OhsA08qkyKL4qdUHpADVL6v5R0&e= > VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
Frisco, TX 75034, USA Mobile: +1.469.556.9450
Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston with Josh Bregman and Paul Done Book Home Page: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wrox.com_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=pyMmnscielr3hC7gWtaVNqyUIqmy1jf4wWg996YlkUI&e=
Kindle Version: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.amazon.com_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=hTJHlTeI3Pk6q1pSEHNHzc-xHC9n3wIYawL8FK3y5Qk&e=
-----Original Message-----
From: Christian Schulte [mailto:cs@schulte.it]
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: info@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range
Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?
> According to
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_ref_3.3.9_maven-2Dartifact_apidocs_org_apache_m&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=9TNP5ldPDafRzXnPjonmLhbp5M5SK1htUhzsTE-Xp4Y&e=
> aven/artifact/versioning/ComparableVersion.html, the range
> [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0
> prerelease versions but not the 2.0 GA release so there is no reason
> you need [1.0,2.0) to do the exact same thing... :-)
>
I haven't tested this but I think what is written here also applies to Maven. You would need to test that yourself.
<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.eclipse.org_Aether_New-5Fand-5FNoteworthy-23Version-5FRanges&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=pL6fPqzqpaj6n6xcY47JGzm-exhIOjBMxuNxWBVBD0U&e= >
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/24/16 um 00:23 schrieb Robert Patrick:
> That one is even worse, pom parsing fails...
>
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for myproject:util:jar must not contain any of these characters \/:"<>|?* but found * @ myproject:zip-installer:[unknown-version], C:\myproject\zipinsall\pom.xml, line 196, column 22
>
Damn it :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
That one is even worse, pom parsing fails...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for myproject:util:jar must not contain any of these characters \/:"<>|?* but found * @ myproject:zip-installer:[unknown-version], C:\myproject\zipinsall\pom.xml, line 196, column 22
-----Original Message-----
From: Christian Schulte [mailto:cs@schulte.it]
Sent: Friday, September 23, 2016 5:17 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range
Am 09/23/16 um 23:38 schrieb Robert Patrick:
> This is nice, but it doesn’t work in Maven 3.3.9...
>
> [ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version ordering: [0.8.min,0.8.max) for project myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]
I have no test project at hand. Did you try "[0.8.*]" as well?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/23/16 um 23:38 schrieb Robert Patrick:
> This is nice, but it doesn\u2019t work in Maven 3.3.9...
>
> [ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version ordering: [0.8.min,0.8.max) for project myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]
I have no test project at hand. Did you try "[0.8.*]" as well?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
This is nice, but it doesn’t work in Maven 3.3.9...
[ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version ordering: [0.8.min,0.8.max) for project myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]
--
Robert Patrick <ro...@oracle.com>
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
Frisco, TX 75034, USA Mobile: +1.469.556.9450
Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/
-----Original Message-----
From: Christian Schulte [mailto:cs@schulte.it]
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: info@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range
Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?
> According to
> https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/m
> aven/artifact/versioning/ComparableVersion.html, the range
> [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0
> prerelease versions but not the 2.0 GA release so there is no reason
> you need [1.0,2.0) to do the exact same thing... :-)
>
I haven't tested this but I think what is written here also applies to Maven. You would need to test that yourself.
<http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges>
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right? According to https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html, the range [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0 prerelease versions but not the 2.0 GA release so there is no reason you need [1.0,2.0) to do the exact same thing... :-)
>
I haven't tested this but I think what is written here also applies to
Maven. You would need to test that yourself.
<http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges>
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
There is already a syntax to give you pre-release versions, right? According to https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html, the range [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0 prerelease versions but not the 2.0 GA release so there is no reason you need [1.0,2.0) to do the exact same thing... :-)
Mark D's workaround is a pragmatic approach.
As for why I don’t get involved, I tend to be selective about where I spend my time and since we eliminated the use of version ranges in our projects for multiple reasons, addressing this issue doesn't really meet my bar for investing my time to contribute. I do contribute periodically, still waiting on my latest bug fix to be integrated (https://issues.apache.org/jira/browse/MNG-5889)...
Cheers,
Robert
-----Original Message-----
From: Curtis Rueden [mailto:ctrueden@wisc.edu]
Sent: Friday, September 23, 2016 3:45 PM
To: Maven Users List
Cc: info@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range
Hi Robert,
> most people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included. I have yet to
> hear you or anyone else give me a use case where you want this.
Personally, I want prerelease versions included.
I think it is unsubstantiated to claim "most people" here.
> There should be a simple way to achieve this
I agree. Why not propose a new syntax, or even a patch? Maven is open source.
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/
On Fri, Sep 23, 2016 at 3:41 PM, Robert Patrick <ro...@oracle.com>
wrote:
> Well...like I said, I understand the relationship but clearly, most
> people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included. I have yet to
> hear you or anyone else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I
> have been using Maven for many years now. There should be a simple
> way to achieve this that does not require me to do something like this:
>
> [1.0,1.999999999999999999999999999999999999999999999999999999999999
> 999999999999999999999999999)
>
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> >
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
> > a valid use case for why Maven should consider > pre-released
> versions as within the "not including 2.0" version > range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the
> final release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Robert,
> most people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included. I have yet to
> hear you or anyone else give me a use case where you want this.
Personally, I want prerelease versions included.
I think it is unsubstantiated to claim "most people" here.
> There should be a simple way to achieve this
I agree. Why not propose a new syntax, or even a patch? Maven is open
source.
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/
On Fri, Sep 23, 2016 at 3:41 PM, Robert Patrick <ro...@oracle.com>
wrote:
> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included. I have yet to hear you or anyone
> else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now. There should be a simple way to
> achieve this that does not require me to do something like this:
>
> [1.0,1.999999999999999999999999999999999999999999999999999999999999
> 999999999999999999999999999)
>
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> >
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
> > a valid use case for why Maven should consider > pre-released versions
> as within the "not including 2.0" version > range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
Well...like I said, I understand the relationship but clearly, most people that use version ranges that use a non-inclusive top-end specification do not want prerelease versions included. I have yet to hear you or anyone else give me a use case where you want this.
The fact that I have to fight Maven to achieve this is a pain--and I have been using Maven for many years now. There should be a simple way to achieve this that does not require me to do something like this:
[1.0,1.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999)
-----Original Message-----
From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
Sent: Friday, September 23, 2016 3:30 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range
Hi,
On 23/09/16 18:38, Robert Patrick wrote:
>
> What I am questioning is the "engineer's approach" to version range
> resolution without
> a valid use case for why Maven should consider > pre-released versions as within the "not including 2.0" version > range semantics.
The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final release (2.0) so must be defined as before...
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
BTW the behaviour of Maven's version comparision can be simply
shown by using the following:
java -jar /usr/local/apache-maven-3.3.9/lib/maven-artifact-3.3.9.jar
2.0-alpha-1 2.0-SNAPSHOT
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 2.0-alpha-1 == 2-alpha-1
2.0-alpha-1 < 2.0-SNAPSHOT
2. 2.0-SNAPSHOT == 2-snapshot
Kind regards
Karl Heinz Marbaise
PS.: This is part of Maven since Maven
3.2.5(https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330189).
On 23/09/16 22:29, Karl Heinz Marbaise wrote:
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
>>
>> What I am questioning is the "engineer's approach" to version range
>> resolution without
>> a valid use case for why Maven should consider
>> pre-released versions as within the "not including 2.0" version
>> range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the
> final release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 23/09/16 18:38, Robert Patrick wrote:
>
> What I am questioning is the "engineer's approach" to version range resolution without
> a valid use case for why Maven should consider
> pre-released versions as within the "not including 2.0" version
> range semantics.
The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the
final release (2.0) so must be defined as before...
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
So then the right range to keep all 2.0 pre-release artifacts out of the build is [1.0,2.0-a)?
-----Original Message-----
From: Guillaume Boué [mailto:gboue@apache.org]
Sent: Friday, September 23, 2016 12:12 PM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range
Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is documented in ComparableVersion:
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.
Guillaume
Le 23/09/2016 à 18:49, Robert Patrick a écrit :
> I was not suggesting that it could be changed...only that it doesn't make sense (except from a pure mathematical point of view).
>
> Given this "engineer's approach" to version range resolution, it seems like a better idea is simply to say [1.0,2.0-SNAPSHOT). I have verified that this eliminates 2.0-SNAPSHOT versions. However, what I have not verified is what happens when you have other pre-release versions (e.g., 2.0-alpha-1). Is 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release versions like alpha, beta, etc?
>
>
> -----Original Message-----
> From: Manfred Moser [mailto:manfred@simpligility.com]
> Sent: Friday, September 23, 2016 11:47 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Fair enough. From the purely engineering/mathematical point of view it might not make sense. But I dont see a way to get that changed with breaking a TON of other stuff. And I am not even sure if it would be more intuitive instead of just being different.
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
>
>> No, you are making an invalid assumption about what I understand! I
>> completely understand the relationship of SNAPSHOTs and other
>> pre-release artifacts and released versions.
>>
>> What I am questioning is the "engineer's approach" to version range
>> resolution without a valid use case for why Maven should consider
>> pre-released versions as within the "not including 2.0" version range semantics.
>>
>>
>> -----Original Message-----
>> From: Manfred Moser [mailto:manfred@simpligility.com]
>> Sent: Friday, September 23, 2016 11:32 AM
>> To: users@maven.apache.org
>> Subject: Re: [EXTERNAL] Re: help with version range
>>
>> What you are misunderstanding is how snapshots are meant to be used.
>> 2.0-SNAPSHOT means that it is a development version working towards
>> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>>
>> If you mislike this you can change how you work with your own
>> projects at least. .. you can just call your snapshot version
>> 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 ..
>>
>> Manfred
>>
>> Robert Patrick wrote on 2016-09-23 08:56:
>>
>>> This does seem non-intuitive. If I say that I want versions between 1.0
>>> and
>>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
>>> would I ever want this to resolve to 2.0-SNAPSHOT or any other
>>> pre-release 2.0 artifact?
>>> Personally, I cannot think of a single one.
>>>
>>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
>>> nothing related to 2.0...
>>>
>>> -----Original Message-----
>>> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
>>> Sent: Friday, September 23, 2016 10:11 AM
>>> To: Maven Users List
>>> Subject: RE: [EXTERNAL] Re: help with version range
>>>
>>> Yeah, I was hoping there was something more elegant like 1.1+ or
>>> something, so I can at least move forward with that.
>>>
>>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
>>> has excluded 1.2.0 from their range? If I explicitly don't want the
>>> release version why would I want the pre-release versions?
>>>
>>> -----Original Message-----
>>> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
>>> Behalf Of Curtis Rueden
>>> Sent: Friday, September 23, 2016 9:01 AM
>>> To: Maven Users List
>>> Subject: [EXTERNAL] Re: help with version range
>>>
>>> Hi Justin,
>>>
>>> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would
>>> match the versions you want in practice.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>>>
>>>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
>>>> it had been going well. However I wanted to start working on 1.2.0
>>>> of the parent, so I published a 1.2.0-alpha-1 version. And all the
>>>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that
>>>> this is in keeping with the implementation that
>>>> x.y.z-(alpha|beta|…) precedes x.y.z, but it is unintuitive to me.
>>>> First in that I’ve stated I don’t want 1.2.0, and second that once
>>>> I do release 1.2.0 the projects which were receiving the alpha
>>>> builds will not get 1.2.0. I tried with both
>>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>>
>>>>
>>>>
>>>> *Justin Georgeson*
>>>> Landmark Cloud Platforms & DevOps - RM
>>>>
>>>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>>>
>>>> Follow Halliburton: *LinkedIn*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2D
>>>> h
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>>> u
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIF
>>>> a
>>>> Q
>>>> &
>>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz
>>>> _
>>>> O
>>>> V
>>>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8
>>>> & s = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>>>> | *Facebook*
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2
>>>> D
>>>> h
>>>> o
>>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsigna
>>>> t
>>>> u
>>>> r
>>>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=P
>>>> s
>>>> k
>>>> v
>>>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1
>>>> u
>>>> y
>>>> u
>>>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT
>>>> - w O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>>>> | *Twitter*
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2
>>>> D
>>>> h
>>>> o
>>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsigna
>>>> t
>>>> u
>>>> r
>>>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=Pskvix
>>>> t
>>>> E
>>>> U
>>>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4
>>>> Q
>>>> o
>>>> E
>>>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8
>>>> N
>>>> W
>>>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>>>> | *YouTube*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2D
>>>> h
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>>> u
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtE
>>>> U
>>>> D
>>>> K
>>>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Qo
>>>> E
>>>> m
>>>> B
>>>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdj
>>>> Y
>>>> S
>>>> K
>>>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>>>> | *Blog*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2D
>>>> h
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>>> u
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7
>>>> w
>>>> u
>>>> W
>>>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBC
>>>> j
>>>> C
>>>> m
>>>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaF
>>>> T
>>>> 0
>>>> -
>>>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>>>
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.
>>>> s
>>>> o
>>>> l
>>>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dL
>>>> x
>>>> Y
>>>> M
>>>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4Dqe
>>>> f D D
>>>> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e=
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> This e-mail, including any attached files, may contain confidential
>>>> and privileged information for the sole use of the intended recipient.
>>>> Any review, use, distribution, or disclosure by others is strictly
>>>> prohibited.
>>>> If you are not the intended recipient (or authorized to receive
>>>> information for the intended recipient), please contact the sender
>>>> by reply e-mail and delete all copies of this message.
>>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Guillaume Boué <gb...@apache.org>.
Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is
documented in ComparableVersion:
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.
Guillaume
Le 23/09/2016 � 18:49, Robert Patrick a �crit :
> I was not suggesting that it could be changed...only that it doesn't make sense (except from a pure mathematical point of view).
>
> Given this "engineer's approach" to version range resolution, it seems like a better idea is simply to say [1.0,2.0-SNAPSHOT). I have verified that this eliminates 2.0-SNAPSHOT versions. However, what I have not verified is what happens when you have other pre-release versions (e.g., 2.0-alpha-1). Is 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release versions like alpha, beta, etc?
>
>
> -----Original Message-----
> From: Manfred Moser [mailto:manfred@simpligility.com]
> Sent: Friday, September 23, 2016 11:47 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Fair enough. From the purely engineering/mathematical point of view it might not make sense. But I dont see a way to get that changed with breaking a TON of other stuff. And I am not even sure if it would be more intuitive instead of just being different.
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
>
>> No, you are making an invalid assumption about what I understand! I
>> completely understand the relationship of SNAPSHOTs and other
>> pre-release artifacts and released versions.
>>
>> What I am questioning is the "engineer's approach" to version range
>> resolution without a valid use case for why Maven should consider
>> pre-released versions as within the "not including 2.0" version range semantics.
>>
>>
>> -----Original Message-----
>> From: Manfred Moser [mailto:manfred@simpligility.com]
>> Sent: Friday, September 23, 2016 11:32 AM
>> To: users@maven.apache.org
>> Subject: Re: [EXTERNAL] Re: help with version range
>>
>> What you are misunderstanding is how snapshots are meant to be used.
>> 2.0-SNAPSHOT means that it is a development version working towards
>> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>>
>> If you mislike this you can change how you work with your own projects
>> at least. .. you can just call your snapshot version 1.99-SNAPSHOT or
>> whatever while developing and at releas time switch to 2.0 ..
>>
>> Manfred
>>
>> Robert Patrick wrote on 2016-09-23 08:56:
>>
>>> This does seem non-intuitive. If I say that I want versions between 1.0
>>> and
>>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
>>> would I ever want this to resolve to 2.0-SNAPSHOT or any other
>>> pre-release 2.0 artifact?
>>> Personally, I cannot think of a single one.
>>>
>>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
>>> nothing related to 2.0...
>>>
>>> -----Original Message-----
>>> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
>>> Sent: Friday, September 23, 2016 10:11 AM
>>> To: Maven Users List
>>> Subject: RE: [EXTERNAL] Re: help with version range
>>>
>>> Yeah, I was hoping there was something more elegant like 1.1+ or
>>> something, so I can at least move forward with that.
>>>
>>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
>>> has excluded 1.2.0 from their range? If I explicitly don't want the
>>> release version why would I want the pre-release versions?
>>>
>>> -----Original Message-----
>>> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
>>> Behalf Of Curtis Rueden
>>> Sent: Friday, September 23, 2016 9:01 AM
>>> To: Maven Users List
>>> Subject: [EXTERNAL] Re: help with version range
>>>
>>> Hi Justin,
>>>
>>> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match
>>> the versions you want in practice.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>>>
>>>> I\u2019m using the parent version range feature with \u201c[1.1.0,1.2.0)\u201d and
>>>> it had been going well. However I wanted to start working on 1.2.0
>>>> of the parent, so I published a 1.2.0-alpha-1 version. And all the
>>>> projects with te \u201c[1.1.0,1.2.0)\u201d picked it up. I recognize that this
>>>> is in keeping with the implementation that x.y.z-(alpha|beta|\u2026)
>>>> precedes x.y.z, but it is unintuitive to me. First in that I\u2019ve
>>>> stated I don\u2019t want 1.2.0, and second that once I do release 1.2.0
>>>> the projects which were receiving the alpha builds will not get
>>>> 1.2.0. I tried with both
>>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>>
>>>>
>>>>
>>>> *Justin Georgeson*
>>>> Landmark Cloud Platforms & DevOps - RM
>>>>
>>>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>>>
>>>> Follow Halliburton: *LinkedIn*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFa
>>>> Q
>>>> &
>>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_
>>>> O
>>>> V
>>>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&
>>>> s = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>>>> | *Facebook*
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2D
>>>> h
>>>> o
>>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>>> u
>>>> r
>>>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Ps
>>>> k
>>>> v
>>>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1u
>>>> y
>>>> u
>>>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-
>>>> w O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>>>> | *Twitter*
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2D
>>>> h
>>>> o
>>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>>> u
>>>> r
>>>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=Pskvixt
>>>> E
>>>> U
>>>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Q
>>>> o
>>>> E
>>>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8N
>>>> W
>>>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>>>> | *YouTube*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEU
>>>> D
>>>> K
>>>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>>>> m
>>>> B
>>>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjY
>>>> S
>>>> K
>>>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>>>> | *Blog*
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>>> o
>>>> s
>>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>>> r
>>>> e
>>>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7w
>>>> u
>>>> W
>>>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCj
>>>> C
>>>> m
>>>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT
>>>> 0
>>>> -
>>>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>>>
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.s
>>>> o
>>>> l
>>>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLx
>>>> Y
>>>> M
>>>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4Dqef
>>>> D D ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e=
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> This e-mail, including any attached files, may contain confidential
>>>> and privileged information for the sole use of the intended recipient.
>>>> Any review, use, distribution, or disclosure by others is strictly
>>>> prohibited.
>>>> If you are not the intended recipient (or authorized to receive
>>>> information for the intended recipient), please contact the sender
>>>> by reply e-mail and delete all copies of this message.
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---
L'absence de virus dans ce courrier �lectronique a �t� v�rifi�e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
I was not suggesting that it could be changed...only that it doesn't make sense (except from a pure mathematical point of view).
Given this "engineer's approach" to version range resolution, it seems like a better idea is simply to say [1.0,2.0-SNAPSHOT). I have verified that this eliminates 2.0-SNAPSHOT versions. However, what I have not verified is what happens when you have other pre-release versions (e.g., 2.0-alpha-1). Is 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release versions like alpha, beta, etc?
-----Original Message-----
From: Manfred Moser [mailto:manfred@simpligility.com]
Sent: Friday, September 23, 2016 11:47 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range
Fair enough. From the purely engineering/mathematical point of view it might not make sense. But I dont see a way to get that changed with breaking a TON of other stuff. And I am not even sure if it would be more intuitive instead of just being different.
Manfred
Robert Patrick wrote on 2016-09-23 09:38:
> No, you are making an invalid assumption about what I understand! I
> completely understand the relationship of SNAPSHOTs and other
> pre-release artifacts and released versions.
>
> What I am questioning is the "engineer's approach" to version range
> resolution without a valid use case for why Maven should consider
> pre-released versions as within the "not including 2.0" version range semantics.
>
>
> -----Original Message-----
> From: Manfred Moser [mailto:manfred@simpligility.com]
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards
> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>
> If you mislike this you can change how you work with your own projects
> at least. .. you can just call your snapshot version 1.99-SNAPSHOT or
> whatever while developing and at releas time switch to 2.0 ..
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 08:56:
>
>> This does seem non-intuitive. If I say that I want versions between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other
>> pre-release 2.0 artifact?
>> Personally, I cannot think of a single one.
>>
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
>> nothing related to 2.0...
>>
>> -----Original Message-----
>> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>>
>> Yeah, I was hoping there was something more elegant like 1.1+ or
>> something, so I can at least move forward with that.
>>
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
>> has excluded 1.2.0 from their range? If I explicitly don't want the
>> release version why would I want the pre-release versions?
>>
>> -----Original Message-----
>> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>>
>> Hi Justin,
>>
>> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match
>> the versions you want in practice.
>>
>> Regards,
>> Curtis
>>
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>>
>>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
>>> it had been going well. However I wanted to start working on 1.2.0
>>> of the parent, so I published a 1.2.0-alpha-1 version. And all the
>>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
>>> is in keeping with the implementation that x.y.z-(alpha|beta|…)
>>> precedes x.y.z, but it is unintuitive to me. First in that I’ve
>>> stated I don’t want 1.2.0, and second that once I do release 1.2.0
>>> the projects which were receiving the alpha builds will not get
>>> 1.2.0. I tried with both
>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>>
>>> Follow Halliburton: *LinkedIn*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>> o
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>> r
>>> e
>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFa
>>> Q
>>> &
>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_
>>> O
>>> V
>>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&
>>> s = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>>> | *Facebook*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2D
>>> h
>>> o
>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>> u
>>> r
>>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Ps
>>> k
>>> v
>>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1u
>>> y
>>> u
>>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-
>>> w O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>>> | *Twitter*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2D
>>> h
>>> o
>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignat
>>> u
>>> r
>>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=Pskvixt
>>> E
>>> U
>>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Q
>>> o
>>> E
>>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8N
>>> W
>>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>>> | *YouTube*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>> o
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>> r
>>> e
>>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEU
>>> D
>>> K
>>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>>> m
>>> B
>>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjY
>>> S
>>> K
>>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>>> | *Blog*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
>>> o
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>> r
>>> e
>>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7w
>>> u
>>> W
>>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCj
>>> C
>>> m
>>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT
>>> 0
>>> -
>>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.s
>>> o
>>> l
>>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLx
>>> Y
>>> M
>>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4Dqef
>>> D D ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e=
>>> >
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> This e-mail, including any attached files, may contain confidential
>>> and privileged information for the sole use of the intended recipient.
>>> Any review, use, distribution, or disclosure by others is strictly
>>> prohibited.
>>> If you are not the intended recipient (or authorized to receive
>>> information for the intended recipient), please contact the sender
>>> by reply e-mail and delete all copies of this message.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Manfred Moser <ma...@simpligility.com>.
Fair enough. From the purely engineering/mathematical point of view it might not make sense. But I dont see a way to get that changed with breaking a TON of other stuff. And I am not even sure if it would be more intuitive instead of just being different.
Manfred
Robert Patrick wrote on 2016-09-23 09:38:
> No, you are making an invalid assumption about what I understand! I completely
> understand the relationship of SNAPSHOTs and other pre-release artifacts and
> released versions.
>
> What I am questioning is the "engineer's approach" to version range resolution
> without a valid use case for why Maven should consider pre-released versions as
> within the "not including 2.0" version range semantics.
>
>
> -----Original Message-----
> From: Manfred Moser [mailto:manfred@simpligility.com]
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards the release
> of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>
> If you mislike this you can change how you work with your own projects at
> least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever
> while developing and at releas time switch to 2.0 ..
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 08:56:
>
>> This does seem non-intuitive. If I say that I want versions between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0
>> artifact?
>> Personally, I cannot think of a single one.
>>
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
>> nothing related to 2.0...
>>
>> -----Original Message-----
>> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>>
>> Yeah, I was hoping there was something more elegant like 1.1+ or
>> something, so I can at least move forward with that.
>>
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
>> has excluded 1.2.0 from their range? If I explicitly don't want the
>> release version why would I want the pre-release versions?
>>
>> -----Original Message-----
>> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>>
>> Hi Justin,
>>
>> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match
>> the versions you want in practice.
>>
>> Regards,
>> Curtis
>>
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>>
>>> I\u2019m using the parent version range feature with \u201c[1.1.0,1.2.0)\u201d and
>>> it had been going well. However I wanted to start working on 1.2.0 of
>>> the parent, so I published a 1.2.0-alpha-1 version. And all the
>>> projects with te \u201c[1.1.0,1.2.0)\u201d picked it up. I recognize that this
>>> is in keeping with the implementation that x.y.z-(alpha|beta|\u2026)
>>> precedes x.y.z, but it is unintuitive to me. First in that I\u2019ve
>>> stated I don\u2019t want 1.2.0, and second that once I do release 1.2.0
>>> the projects which were receiving the alpha builds will not get
>>> 1.2.0. I tried with both
>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>>
>>> Follow Halliburton: *LinkedIn*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>>> e
>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
>>> &
>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
>>> V
>>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
>>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>>> | *Facebook*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>>> o
>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>> r
>>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Psk
>>> v
>>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uy
>>> u
>>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-w
>>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>>> | *Twitter*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>>> o
>>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>>> r
>>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtE
>>> U
>>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Qo
>>> E
>>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW
>>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>>> | *YouTube*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>>> e
>>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUD
>>> K
>>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
>>> B
>>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYS
>>> K
>>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>>> | *Blog*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>>> s
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>>> e
>>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wu
>>> W
>>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjC
>>> m
>>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0
>>> -
>>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.so
>>> l
>>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxY
>>> M
>>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefD
>>> D ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> This e-mail, including any attached files, may contain confidential
>>> and privileged information for the sole use of the intended recipient.
>>> Any review, use, distribution, or disclosure by others is strictly
>>> prohibited.
>>> If you are not the intended recipient (or authorized to receive
>>> information for the intended recipient), please contact the sender by
>>> reply e-mail and delete all copies of this message.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
No, you are making an invalid assumption about what I understand! I completely understand the relationship of SNAPSHOTs and other pre-release artifacts and released versions.
What I am questioning is the "engineer's approach" to version range resolution without a valid use case for why Maven should consider pre-released versions as within the "not including 2.0" version range semantics.
-----Original Message-----
From: Manfred Moser [mailto:manfred@simpligility.com]
Sent: Friday, September 23, 2016 11:32 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range
What you are misunderstanding is how snapshots are meant to be used. 2.0-SNAPSHOT means that it is a development version working towards the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
If you mislike this you can change how you work with your own projects at least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 ..
Manfred
Robert Patrick wrote on 2016-09-23 08:56:
> This does seem non-intuitive. If I say that I want versions between 1.0 and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact?
> Personally, I cannot think of a single one.
>
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
> nothing related to 2.0...
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
>
> Yeah, I was hoping there was something more elegant like 1.1+ or
> something, so I can at least move forward with that.
>
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> has excluded 1.2.0 from their range? If I explicitly don't want the
> release version why would I want the pre-release versions?
>
> -----Original Message-----
> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On
> Behalf Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
>
> Hi Justin,
>
> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match
> the versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>
>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
>> it had been going well. However I wanted to start working on 1.2.0 of
>> the parent, so I published a 1.2.0-alpha-1 version. And all the
>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
>> is in keeping with the implementation that x.y.z-(alpha|beta|…)
>> precedes x.y.z, but it is unintuitive to me. First in that I’ve
>> stated I don’t want 1.2.0, and second that once I do release 1.2.0
>> the projects which were receiving the alpha builds will not get
>> 1.2.0. I tried with both
>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>
>> Follow Halliburton: *LinkedIn*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>> s
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> e
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
>> &
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
>> V
>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>> | *Facebook*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Psk
>> v
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uy
>> u
>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-w
>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>> | *Twitter*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtE
>> U
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4Qo
>> E
>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW
>> 2 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>> | *YouTube*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>> s
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> e
>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUD
>> K
>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm
>> B
>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYS
>> K
>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>> | *Blog*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>> s
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> e
>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wu
>> W
>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjC
>> m
>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0
>> -
>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.so
>> l
>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxY
>> M
>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefD
>> D ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>>
>>
>>
>>
>> ------------------------------
>> This e-mail, including any attached files, may contain confidential
>> and privileged information for the sole use of the intended recipient.
>> Any review, use, distribution, or disclosure by others is strictly prohibited.
>> If you are not the intended recipient (or authorized to receive
>> information for the intended recipient), please contact the sender by
>> reply e-mail and delete all copies of this message.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Manfred Moser <ma...@simpligility.com>.
What you are misunderstanding is how snapshots are meant to be used. 2.0-SNAPSHOT means that it is a development version working towards the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
If you mislike this you can change how you work with your own projects at least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 ..
Manfred
Robert Patrick wrote on 2016-09-23 08:56:
> This does seem non-intuitive. If I say that I want versions between 1.0 and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever
> want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact?
> Personally, I cannot think of a single one.
>
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing
> related to 2.0...
>
> -----Original Message-----
> From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
>
> Yeah, I was hoping there was something more elegant like 1.1+ or something, so
> I can at least move forward with that.
>
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release version
> why would I want the pre-release versions?
>
> -----Original Message-----
> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On Behalf Of
> Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
>
> Hi Justin,
>
> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match the
> versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>
>> I\u2019m using the parent version range feature with \u201c[1.1.0,1.2.0)\u201d and it
>> had been going well. However I wanted to start working on 1.2.0 of the
>> parent, so I published a 1.2.0-alpha-1 version. And all the projects
>> with te \u201c[1.1.0,1.2.0)\u201d picked it up. I recognize that this is in
>> keeping with the implementation that x.y.z-(alpha|beta|\u2026) precedes
>> x.y.z, but it is unintuitive to me. First in that I\u2019ve stated I don\u2019t
>> want 1.2.0, and second that once I do release 1.2.0 the projects which
>> were receiving the alpha builds will not get 1.2.0. I tried with both
>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>>
>> Follow Halliburton: *LinkedIn*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
>> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>> | *Facebook*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
>> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>> | *Twitter*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
>> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>> | *YouTube*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>> | *Blog*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
>> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
>> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
>> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
>> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
>> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
>> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>>
>>
>>
>>
>> ------------------------------
>> This e-mail, including any attached files, may contain confidential
>> and privileged information for the sole use of the intended recipient.
>> Any review, use, distribution, or disclosure by others is strictly prohibited.
>> If you are not the intended recipient (or authorized to receive
>> information for the intended recipient), please contact the sender by
>> reply e-mail and delete all copies of this message.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Justin Georgeson <JG...@lgc.com>.
Similarly I wouldn't want a range like "[1.2.0,1.3.0)" to give me a pre-release 1.2.0 artifact.
-----Original Message-----
From: Robert Patrick [mailto:robert.patrick@oracle.com]
Sent: Friday, September 23, 2016 10:56 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range
This does seem non-intuitive. If I say that I want versions between 1.0 and up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact? Personally, I cannot think of a single one.
Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing related to 2.0...
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range
Yeah, I was hoping there was something more elegant like 1.1+ or something, so I can at least move forward with that.
Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has excluded 1.2.0 from their range? If I explicitly don't want the release version why would I want the pre-release versions?
-----Original Message-----
From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On Behalf Of Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range
Hi Justin,
You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match the versions you want in practice.
Regards,
Curtis
On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> had been going well. However I wanted to start working on 1.2.0 of the
> parent, so I published a 1.2.0-alpha-1 version. And all the projects
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> want 1.2.0, and second that once I do release 1.2.0 the projects which
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> ------------------------------
> This e-mail, including any attached files, may contain confidential
> and privileged information for the sole use of the intended recipient.
> Any review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive
> information for the intended recipient), please contact the sender by
> reply e-mail and delete all copies of this message.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: [EXTERNAL] Re: help with version range
Posted by Robert Patrick <ro...@oracle.com>.
This does seem non-intuitive. If I say that I want versions between 1.0 and up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact? Personally, I cannot think of a single one.
Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing related to 2.0...
-----Original Message-----
From: Justin Georgeson [mailto:JGeorgeson@lgc.com]
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range
Yeah, I was hoping there was something more elegant like 1.1+ or something, so I can at least move forward with that.
Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has excluded 1.2.0 from their range? If I explicitly don't want the release version why would I want the pre-release versions?
-----Original Message-----
From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On Behalf Of Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range
Hi Justin,
You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match the versions you want in practice.
Regards,
Curtis
On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> had been going well. However I wanted to start working on 1.2.0 of the
> parent, so I published a 1.2.0-alpha-1 version. And all the projects
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> want 1.2.0, and second that once I do release 1.2.0 the projects which
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> ------------------------------
> This e-mail, including any attached files, may contain confidential
> and privileged information for the sole use of the intended recipient.
> Any review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive
> information for the intended recipient), please contact the sender by
> reply e-mail and delete all copies of this message.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [EXTERNAL] Re: help with version range
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Justin,
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> has excluded 1.2.0 from their range? If I explicitly don't want the
> release version why would I want the pre-release versions?
I think it really depends how you use those version suffixes. For example,
I have a component which is currently at 2.0.0-rc-55 (yeah, yeah, 55
"release candidates" is insane, I know). To me, it makes sense that
[1.0.0,2.0.0-rc-55) should match 2.0.0-rc-54.
Anyway, it is way too late to change the behavior. But you're right that an
enhancement to the syntax here might be doable. I leave it to the Maven
core folks to comment on that though.
Regards,
Curtis
On Fri, Sep 23, 2016 at 10:11 AM, Justin Georgeson <JG...@lgc.com>
wrote:
> Yeah, I was hoping there was something more elegant like 1.1+ or
> something, so I can at least move forward with that.
>
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release
> version why would I want the pre-release versions?
>
> -----Original Message-----
> From: ctrueden.wisc@gmail.com [mailto:ctrueden.wisc@gmail.com] On Behalf
> Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
>
> Hi Justin,
>
> You could write "[1.1.0,1.1.99999]", no? A bit hacky, but would match the
> versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <JG...@lgc.com> wrote:
>
> > I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> > had been going well. However I wanted to start working on 1.2.0 of the
> > parent, so I published a 1.2.0-alpha-1 version. And all the projects
> > with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> > keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> > x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> > want 1.2.0, and second that once I do release 1.2.0 the projects which
> > were receiving the alpha builds will not get 1.2.0. I tried with both
> > 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >
> >
> >
> > *Justin Georgeson*
> > Landmark Cloud Platforms & DevOps - RM
> >
> > Email: *jgeorgeson@lgc.com* <jg...@lgc.com>
> >
> > Follow Halliburton: *LinkedIn*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> > c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> > ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> > 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> > | *Facebook*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> > ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> > i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> > jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> > | *Twitter*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> > DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> > mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> > 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> > | *YouTube*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> > 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> > CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> > _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> > | *Blog*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> > U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> > EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> > BpnvVYmC73xtz0gLUBwIg5Woho&e= >
> >
> >
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> > utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> > 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> > ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
> >
> >
> >
> >
> > ------------------------------
> > This e-mail, including any attached files, may contain confidential
> > and privileged information for the sole use of the intended recipient.
> > Any review, use, distribution, or disclosure by others is strictly
> prohibited.
> > If you are not the intended recipient (or authorized to receive
> > information for the intended recipient), please contact the sender by
> > reply e-mail and delete all copies of this message.
> >
>