Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match
> >> the versions you want in practice.
> >> 
> >> Regards,
> >> Curtis
> >> 
> >> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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

Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

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.9
> 99)
> 
> 
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[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.

I like the colorized output.

-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 8:47 PM
To: Maven Users List <users@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=DQICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2F
> ZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=leobnERpx7eIg
> IvKmjTYhgj8buTHbUXeP5uyujIxsBY=WtN5v0mIkuOLd0hI4m_OpYLLsyZGYi6ivI7n6
> lvH6gw=
> 
> 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_=DQICaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=leobnERpx7eIgIvKmjTYhgj8buTHbUXeP5uyujIxsBY=R4EYmMCVXobVq6h9SfS4A9EtWGvXSOLvTqmjLIMelbY=
 >

Regards,
--
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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

[Christian Schulte]

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.



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[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.

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Friday, September 23, 2016 4:39 PM
To: Maven Users List <users@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=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU=euuADbCvIIw3JpW95OhsA08qkyKL4qdUHpADVL6v5R0=
 > 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_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU=pyMmnscielr3hC7gWtaVNqyUIqmy1jf4wWg996YlkUI=
Kindle Version: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.amazon.com_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU=hTJHlTeI3Pk6q1pSEHNHzc-xHC9n3wIYawL8FK3y5Qk=
 


-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: i...@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=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU=9TNP5ldPDafRzXnPjonmLhbp5M5SK1htUhzsTE-Xp4Y=
>  
> 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=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU=pL6fPqzqpaj6n6xcY47JGzm-exhIOjBMxuNxWBVBD0U=
 >

Regards,
--
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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 st

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[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



-Original Message-
From: Christian Schulte [mailto:c...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[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]

--
Robert Patrick <robert.patr...@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:c...@schulte.it] 
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: i...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

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.



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[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... :-)

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:ctrue...@wisc.edu] 
Sent: Friday, September 23, 2016 3:45 PM
To: Maven Users List
Cc: i...@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 <robert.patr...@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.
> 999)
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Curtis Rueden]

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 <robert.patr...@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.
> 999)
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

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.999)


-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Karl Heinz Marbaise]

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=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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Karl Heinz Marbaise]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Robert Scholte]

(2|2.0|2.0.0)-(a|alpha)-SNAPSHOT


Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Robert Patrick 
<robert.patr...@oracle.com> Datum:23-09-2016  11:18  (GMT-08:00) 
Aan: Maven Users List <users@maven.apache.org> Onderwerp: 
RE: [EXTERNAL] Re: help with version range 
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:gb...@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:manf...@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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

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:gb...@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:manf...@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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would 
>>> match the versions you want in practice.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@lgc.com> wrote:
>>>
>>&g

Re: [EXTERNAL] Re: help with version range

[Guillaume Boué]

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:manf...@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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match
the versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFa
Q
&
c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_
O
V
ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&
s = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
| *Fa

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

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:manf...@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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge.

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ
>>> & 
>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_O
>>> V 
>>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8
>>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
>>> | *Facebook*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>>> o 
>>>

Re: [EXTERNAL] Re: help with version range

[Curtis Rueden]

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 <jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match the
> versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ&
> > c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
> > ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
> > 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> > | *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=DQIFaQ=Pskv
> > ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> > i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
> > jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> > | *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=DQIFaQ=PskvixtEU
> > DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> > mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
> > 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
> > | *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=DQIFaQ=PskvixtEUDK
> > 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> > CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
> > _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
> > | *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=DQIFaQ=PskvixtEUDK7wuW
> > U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> > EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
> > BpnvVYmC73xtz0gLUBwIg5Woho= >
> >
> >
> >

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

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:manf...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match 
> the versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ
>> & 
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_O
>> V 
>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8
>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
>> | *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=DQIFaQ=Psk
>> v 
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uy
>> u 
>> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-w
>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
>> | *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=DQIFaQ=PskvixtE
>> U 
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match the
> versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ&
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
>> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
>> | *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=DQIFaQ=Pskv
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
>> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
>> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
>> | *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=DQIFaQ=PskvixtEU
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>> mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
>> 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
>> | *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=DQIFaQ=PskvixtEUDK
>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
>> CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
>> | *Blog*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

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.patr...@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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> | *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=DQIFaQ=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> | *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=DQIFaQ=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
> | *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=DQIFaQ=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
> | *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=DQIFaQ=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

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:jgeorge...@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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> | *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=DQIFaQ=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> | *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=DQIFaQ=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
> | *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=DQIFaQ=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
> | *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=DQIFaQ=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE= >
>
>
>
>
> --
> 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

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

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.w...@gmail.com [mailto:ctrueden.w...@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.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@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: *jgeorge...@lgc.com* <jgeorge...@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=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> | *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=DQIFaQ=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> | *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=DQIFaQ=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
> | *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=DQIFaQ=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
> | *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=DQIFaQ=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_=DQIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE= >
>
>
>
>
> --
> 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.
>