Re: Excluding -beta-N from a range
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
Thanks karl, the version range semantic is much clear now for me. -D On Sun, Jan 15, 2017 at 3:03 AM, Karl Heinz Marbaisewrote: > 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
On Sun, Jan 15, 2017 at 3:01 AM, Karl Heinz Marbaisewrote: > 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
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ätzwrote: 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
Hi, On 13/01/17 16:37, Benson Margulies wrote: On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätzwrote: 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
+1 to fix it at maven-core -D On Fri, Jan 13, 2017 at 7:37 AM, Benson Margulieswrote: > 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
On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätzwrote: > 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
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
On Thu, Jan 12, 2017 at 2:57 PM, Curtis Ruedenwrote: > 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
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 Derricuttwrote: > 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
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