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