Re: Excluding -beta-N from a range

[Lukasz Dywicki]

a range like: 

[1.min,1.max]

Includes 1.0.0-SNAPSHOT and excludes 2.0.0-SNAPSHOT with everything what is
in 1.x (not sure about upper bound and 1.9-rc, beta etc).

Kind regards,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org



--
View this message in context: 
http://maven.40175.n5.nabble.com/Excluding-beta-N-from-a-range-tp5892806p5894368.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Excluding -beta-N from a range

[Dan Tran]

Thanks karl, the version range semantic is much clear now for me.

-D

On Sun, Jan 15, 2017 at 3:03 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 15/01/17 12:01, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> On 13/01/17 16:37, Benson Margulies wrote:
>>
>>> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
>>> wrote:
>>>
 Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:

 I agree with them that this is counter-intuitive. The whole point of
> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> that range is to exclude it.
>

>> If you introduce incompatible stuff you should call it 3.X cause based
>> on SemVer[1] this would be the way to go...
>>
>>
>> [1]: http://semver.org/
>>
>
> Missed a LinK.
>
> [2]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
>
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>>
 Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
 that the final 2.0.0 release will include everything that's in this
 beta, thus the range quite correctly contains it...?

>>>
>>>
>>> The range [1,2) excludes 2.0.0.
>>> So, by your logic, which is my logic,
>>> it should also exclude the beta.
>>>
>>
>> The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to
>> 2.0.0 BUT 2.0.0-beta is less than 2.0 which means it is included the
>> range ...cause based on the timeline 2.0-beta is before 2.0
>>
>> So in the end it does not exclude the beta...
>>
>>
 If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
 release, wouldn't it be better called 2.0.1-beta1?

 Just curious because we had some discussions about versioning strategies
 here, too, a while ago.

>>>
>> Yes I agree...
>>
>> If you having changes which will not being part of 2.0.0 you should call
>> that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline
>>
>> 1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..
>>
>> If you like having something which should be introduces after releasing
>> 2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
 Regards,

 Flo

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

Re: Excluding -beta-N from a range

[Benson Margulies]

On Sun, Jan 15, 2017 at 3:01 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> On 13/01/17 16:37, Benson Margulies wrote:
>>
>> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
>> wrote:
>>>
>>> Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
>>>
 I agree with them that this is counter-intuitive. The whole point of
 -beta-1 is to introduce new, incompatible, stuff. The whole point of
 that range is to exclude it.
>
>
> If you introduce incompatible stuff you should call it 3.X cause based on
> SemVer[1] this would be the way to go...

Yes, indeed, that's exactly what we are doing. We make incompatible
changes, and we move the version from 1.x.y to 2.0.0-beta-1-SNAPSHOT,
and we're still included in the range 2), the job of which is to
_exclude_ 2.0.

>
>
> [1]: http://semver.org/
>
>>>
>>> Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
>>> that the final 2.0.0 release will include everything that's in this
>>> beta, thus the range quite correctly contains it...?
>>
>>
>>
>> The range [1,2) excludes 2.0.0.
>
>> So, by your logic, which is my logic,
>>
>> it should also exclude the beta.
>
>
> The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to 2.0.0
> BUT 2.0.0-beta is less than 2.0 which means it is included the range
> ...cause based on the timeline 2.0-beta is before 2.0
>
> So in the end it does not exclude the beta...
>
>>>
>>> If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
>>> release, wouldn't it be better called 2.0.1-beta1?
>>>
>>> Just curious because we had some discussions about versioning strategies
>>> here, too, a while ago.
>
>
> Yes I agree...
>
> If you having changes which will not being part of 2.0.0 you should call
> that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline
>
> 1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..
>
> If you like having something which should be introduces after releasing
> 2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...
>
>
> Kind regards
> Karl Heinz Marbaise
>
>>>
>>> Regards,
>>>
>>> Flo
>>
>>
>
> -
> 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: Excluding -beta-N from a range

[Karl Heinz Marbaise]

Hi,

On 15/01/17 12:01, Karl Heinz Marbaise wrote:

Hi,

On 13/01/17 16:37, Benson Margulies wrote:

On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
wrote:

Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:


I agree with them that this is counter-intuitive. The whole point of
-beta-1 is to introduce new, incompatible, stuff. The whole point of
that range is to exclude it.


If you introduce incompatible stuff you should call it 3.X cause based
on SemVer[1] this would be the way to go...


[1]: http://semver.org/


Missed a LinK.

[2]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf

Kind regards
Karl Heinz Marbaise




Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
that the final 2.0.0 release will include everything that's in this
beta, thus the range quite correctly contains it...?



The range [1,2) excludes 2.0.0.
So, by your logic, which is my logic,
it should also exclude the beta.


The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to
2.0.0 BUT 2.0.0-beta is less than 2.0 which means it is included the
range ...cause based on the timeline 2.0-beta is before 2.0

So in the end it does not exclude the beta...



If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
release, wouldn't it be better called 2.0.1-beta1?

Just curious because we had some discussions about versioning strategies
here, too, a while ago.


Yes I agree...

If you having changes which will not being part of 2.0.0 you should call
that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline

1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..

If you like having something which should be introduces after releasing
2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...


Kind regards
Karl Heinz Marbaise



Regards,

Flo




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

Re: Excluding -beta-N from a range

[Karl Heinz Marbaise]

Hi,

On 13/01/17 16:37, Benson Margulies wrote:

On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz  wrote:

Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:


I agree with them that this is counter-intuitive. The whole point of
-beta-1 is to introduce new, incompatible, stuff. The whole point of
that range is to exclude it.


If you introduce incompatible stuff you should call it 3.X cause based 
on SemVer[1] this would be the way to go...



[1]: http://semver.org/



Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
that the final 2.0.0 release will include everything that's in this
beta, thus the range quite correctly contains it...?



The range [1,2) excludes 2.0.0.

> So, by your logic, which is my logic,

it should also exclude the beta.


The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to 
2.0.0 BUT 2.0.0-beta is less than 2.0 which means it is included the 
range ...cause based on the timeline 2.0-beta is before 2.0


So in the end it does not exclude the beta...



If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
release, wouldn't it be better called 2.0.1-beta1?

Just curious because we had some discussions about versioning strategies
here, too, a while ago.


Yes I agree...

If you having changes which will not being part of 2.0.0 you should call 
that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline


1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..

If you like having something which should be introduces after releasing 
2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...



Kind regards
Karl Heinz Marbaise



Regards,

Flo




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

Re: Excluding -beta-N from a range

[Dan Tran]

+1 to fix it at maven-core

-D

On Fri, Jan 13, 2017 at 7:37 AM, Benson Margulies 
wrote:

> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz 
> wrote:
> > Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
> >
> >> I agree with them that this is counter-intuitive. The whole point of
> >> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> >> that range is to exclude it.
> >
> > Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
> > that the final 2.0.0 release will include everything that's in this
> > beta, thus the range quite correctly contains it...?
>
>
> The range [1,2) excludes 2.0.0. So, by your logic, which is my logic,
> it should also exclude the beta.
> >
> > If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
> > release, wouldn't it be better called 2.0.1-beta1?
> >
> > Just curious because we had some discussions about versioning strategies
> > here, too, a while ago.
> >
> > Regards,
> >
> > Flo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Excluding -beta-N from a range

[Benson Margulies]

On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz  wrote:
> Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
>
>> I agree with them that this is counter-intuitive. The whole point of
>> -beta-1 is to introduce new, incompatible, stuff. The whole point of
>> that range is to exclude it.
>
> Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
> that the final 2.0.0 release will include everything that's in this
> beta, thus the range quite correctly contains it...?


The range [1,2) excludes 2.0.0. So, by your logic, which is my logic,
it should also exclude the beta.
>
> If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
> release, wouldn't it be better called 2.0.1-beta1?
>
> Just curious because we had some discussions about versioning strategies
> here, too, a while ago.
>
> Regards,
>
> Flo

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

Re: Excluding -beta-N from a range

[Florian Schätz]

Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:

> I agree with them that this is counter-intuitive. The whole point of
> -beta-1 is to introduce new, incompatible, stuff. The whole point of
> that range is to exclude it.

Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
that the final 2.0.0 release will include everything that's in this
beta, thus the range quite correctly contains it...?

If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
release, wouldn't it be better called 2.0.1-beta1?

Just curious because we had some discussions about versioning strategies
here, too, a while ago.

Regards,

Flo

Re: Excluding -beta-N from a range

[Benson Margulies]

On Thu, Jan 12, 2017 at 2:57 PM, Curtis Rueden  wrote:
> Hi Benson,
>
>> I did not know how to tell them how to write a range that has the
>> desired effect. Is there one?
>
> Would it work to use a hacky range like:
> [1.0.0,1..]

That is my fallback advice to them, indeed.

The no '.0.0' release advise will be a bitter pill to swallow.



> ?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>
>
> On Thu, Jan 12, 2017 at 4:52 PM, Mark Derricutt  wrote:
>
>> Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact
>> for this exact reason.
>>
>> Always start with .1
>>
>> Mark
>>
>> --
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
>>
>> On 13 Jan 2017, at 11:22, Benson Margulies wrote:
>>
>> > I did not know how to tell them how to write a range that has the
>> > desired effect. Is there one?
>>

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

Re: Excluding -beta-N from a range

[Curtis Rueden]

Hi Benson,

> I did not know how to tell them how to write a range that has the
> desired effect. Is there one?

Would it work to use a hacky range like:
[1.0.0,1..]
?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Thu, Jan 12, 2017 at 4:52 PM, Mark Derricutt  wrote:

> Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact
> for this exact reason.
>
> Always start with .1
>
> Mark
>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
> On 13 Jan 2017, at 11:22, Benson Margulies wrote:
>
> > I did not know how to tell them how to write a range that has the
> > desired effect. Is there one?
>

Re: Excluding -beta-N from a range

[Mark Derricutt]

Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact for 
this exact reason.

Always start with .1

Mark

-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

On 13 Jan 2017, at 11:22, Benson Margulies wrote:

> I did not know how to tell them how to write a range that has the
> desired effect. Is there one?


signature.asc
Description: OpenPGP digital signature