Hi there, now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously. I see two issues with the current release numbering scheme: 1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ? 2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other. Comments ? Thanks, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Hi there,
now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously.
I see two issues with the current release numbering scheme:
1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ?
2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other.
Comments ?
I'm all for dropping the leading 1. I do think the 2nd number should be retained to reflect the branch. There's always a chance we'll release (1.)34.0 and later find we want to release (1.)33.2 Calling that release 35 would be confusing at best. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I'm all for dropping the leading 1.
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I do think the 2nd number should be retained to reflect the branch. There's always a chance we'll release (1.)34.0 and later find we want to release (1.)33.2
Agreed, we do need a way to identify patch releases. There is a clear distinction between the kind of changes allowed in a 1.X and a 1.X.Y release. AFAICS if we make any changes at all the distinction will only become clearer in the future. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
David Abrahams wrote:
I'm all for dropping the leading 1.
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I have to admit that I don't have any idea of the efford. I would guess it is a single configuration item in some Jamfile or somesuch.
I do think the 2nd number should be retained to reflect the branch. There's always a chance we'll release (1.)34.0 and later find we want to release (1.)33.2
Agreed, we do need a way to identify patch releases. There is a clear distinction between the kind of changes allowed in a 1.X and a 1.X.Y release.
Yes, though these questions only concern the release management (i.e. developers). I do understand David's point. If the timeorder of releases doesn't match the evolution of a single branch, keeping a single number would be confusing to users. Regards, Stefan
On Tue, Dec 06, 2005 at 01:13:52PM -0500, Stefan Seefeld wrote:
Thomas Witt wrote:
David Abrahams wrote:
I'm all for dropping the leading 1.
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I have to admit that I don't have any idea of the effort. I would guess it is a single configuration item in some Jamfile or somesuch.
but it's not just the effort at the Boost side --- it's a worldwide effort. For example at my side: Since the library I'm developing uses Boost, I have integrated building Boost into my build system, so that also inclusion of header files and linking is done automatically, and this for different versions of boost (compiled with different compiler versions). I guess systems like that exist at several places. Now my system obviously relies in some form on the naming conventions. Sure, it shouldn't be too difficult to change this (but it's also not completely trivial in case I want to support also older version of Boost), but there is always the chance that you oversee something, especially regarding build systems and the like where it is really hard to have a reliable automatic test system for this purpose (so yet I don't have one). And then, once I release my library, the users might found out about the bug. Isn't there a saying in the direction of if something runs and there is no real reason to change, then better continue as it is? (Can't remember it's exact wording.) (And in this case there seems to be no reason at all to drop the leading 1.) Furthermore the naming system like 1.33.2 seems to be universally used. And why not having Boost 2.0 at some time? For example with C++ 0x. Oliver
Oliver Kullmann wrote:
Isn't there a saying in the direction of if something runs and there is no real reason to change, then better continue as it is? (Can't remember it's exact wording.)
"If it ain't broken, don't fix it."
(And in this case there seems to be no reason at all to drop the leading 1.)
Furthermore the naming system like 1.33.2 seems to be universally used.
But that is exactly the point ! Not only is it universally used, there are specific semantics associated (i.e. the distinction of major, minor, and patch number) with the triplet. Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Oliver Kullmann wrote:
Isn't there a saying in the direction of if something runs and there is no real reason to change, then better continue as it is? (Can't remember it's exact wording.)
"If it ain't broken, don't fix it."
"If it ain't broke, don't fix it." -- Dave Abrahams Boost Consulting www.boost-consulting.com
Oliver Kullmann <O.Kullmann@swansea.ac.uk> writes:
On Tue, Dec 06, 2005 at 01:13:52PM -0500, Stefan Seefeld wrote:
Thomas Witt wrote:
David Abrahams wrote:
I'm all for dropping the leading 1.
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I have to admit that I don't have any idea of the effort. I would guess it is a single configuration item in some Jamfile or somesuch.
but it's not just the effort at the Boost side --- it's a worldwide effort. For example at my side: Since the library I'm developing uses Boost, I have integrated building Boost into my build system, so that also inclusion of header files and linking is done automatically, and this for different versions of boost (compiled with different compiler versions). I guess systems like that exist at several places. Now my system obviously relies in some form on the naming conventions. Sure, it shouldn't be too difficult to change this (but it's also not completely trivial in case I want to support also older version of Boost), but there is always the chance that you oversee something, especially regarding build systems and the like where it is really hard to have a reliable automatic test system for this purpose (so yet I don't have one). And then, once I release my library, the users might found out about the bug.
Isn't there a saying in the direction of if something runs and there is no real reason to change, then better continue as it is? (Can't remember it's exact wording.) (And in this case there seems to be no reason at all to drop the leading 1.)
It seems to me that 34.0.0 ought to be just as compatible with your system for the next Boost version as 1.34.0 is... no?
Furthermore the naming system like 1.33.2 seems to be universally used.
So we should add a trailing zero, in case we ever decide to maintain some kind of compatibility with a patch release.
And why not having Boost 2.0 at some time? For example with C++ 0x.
I don't think Boost's major version number should change when, and only when, there's a new version C++. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Stefan Stefan Seefeld wrote:
Thomas Witt wrote:
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I have to admit that I don't have any idea of the efford. I would guess it is a single configuration item in some Jamfile or somesuch.
Well Murphy says it's certainly more than one place. Even if it's just a single place there is the effort of communicating that change.
Agreed, we do need a way to identify patch releases. There is a clear distinction between the kind of changes allowed in a 1.X and a 1.X.Y release.
Yes, though these questions only concern the release management (i.e. developers).
I am not sure I understand you correctly. AFAICS this is of concern to the users in terms of API compatibility, likeliness of regressions and such. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Agreed, we do need a way to identify patch releases. There is a clear distinction between the kind of changes allowed in a 1.X and a 1.X.Y release.
Yes, though these questions only concern the release management (i.e. developers).
I am not sure I understand you correctly. AFAICS this is of concern to the users in terms of API compatibility, likeliness of regressions and such.
Is there any guarantee about what can and can not change between major and minor releases ? If so, it should be documented. If not, i.e. if it is only a matter of 'likeliness', I honestly don't see much point in trying to draw a distinction. Regards, Stefan
Thomas Witt <witt@acm.org> writes:
David Abrahams wrote:
I'm all for dropping the leading 1.
Yes it is meaningless, but is it worth the effort? Personally I don't think so, we have bigger fish to fry.
I don't think it takes any significant effort at all to name the next release 34.0 instead of 1.34.0 -- Dave Abrahams Boost Consulting www.boost-consulting.com
Dave, David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
I'm all for dropping the leading 1. Yes it is meaningless, but is it worth the effort? Personally I don't
David Abrahams wrote: think so, we have bigger fish to fry.
I don't think it takes any significant effort at all to name the next release 34.0 instead of 1.34.0
I think you are underestimating the effort. There is QA, i.e. finding all the places the version number is used. I don't even want to think about library naming schemes and such. Then as mentioned earlier the change has to be communicated to users with respect to rationale and what it means. What is kind of related is the ripple effect for users. See Olivers post with respect to this. This applies to communication too. Think about telling management/legal department you want to move from 1.33 to 34.0 if that does not draw questions I don't know what will. That being said, after thinking about it for a while I have to say I am not really ready to give up on the major version number. If we ever get around modularizing boost this might justify calling it 2.x. Thomas -- Thomas Witt witt@acm.org
I think you are underestimating the effort. There is QA, i.e. finding all the places the version number is used. I don't even want to think about library naming schemes and such.
It's used in two places: the Boost.Build and boost/version.hpp everything else (including library naming schemes etc, pick up the numbers from there. As has been said before, changing to 34.0 is no harder than changing to 1.43. John.
Why don't we just call it boost 2006.NET. (I am not serious by the way) If the only benefit we get from changing is a re-branding then I don't see it as worth the effort. On 12/7/05, John Maddock <john@johnmaddock.co.uk> wrote:
As has been said before, changing to 34.0 is no harder than changing to 1.43.
There may be little effort from the boost point of view, but users will be affected, as Oliver said. Probably much more than we expect. I can think of several scripts I have that use the boost version number, moving up a version for me is as simple as changing a variable Changing the structuring of the version number would mean hacking the script so that for versions < 34 produce 1.34 and >= 34 produce 34.0. Why? Who benefits? As for the psychological side, I see a version like 34.0 as "Wow, it took them 33 versions before they got it right?", whereas 1.34 as "its in active development". Sam
Thomas Witt <witt@acm.org> writes:
Dave,
David Abrahams wrote:
Thomas Witt <witt@acm.org> writes:
I'm all for dropping the leading 1. Yes it is meaningless, but is it worth the effort? Personally I don't
David Abrahams wrote: think so, we have bigger fish to fry.
I don't think it takes any significant effort at all to name the next release 34.0 instead of 1.34.0
I think you are underestimating the effort. There is QA, i.e. finding all the places the version number is used.
Why would anyone need to do that? Are people depending on Boost version numbers being strictly sequential?
I don't even want to think about library naming schemes and such. Then as mentioned earlier the change has to be communicated to users with respect to rationale and what it means. What is kind of related is the ripple effect for users. See Olivers post with respect to this. This applies to communication too. Think about telling management/legal department you want to move from 1.33 to 34.0 if that does not draw questions I don't know what will.
That being said, after thinking about it for a while I have to say I am not really ready to give up on the major version number. If we ever get around modularizing boost this might justify calling it 2.x.
I don't care much about this issue at all, FWIW. I'm just curious, is all. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Stefan Seefeld wrote:
Hi there,
now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously.
I see two issues with the current release numbering scheme:
1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ?
I agree, the use of the "1." is questionable. However, we could reserve 2.x.y for a version of Boost that does not contain any workarounds for ancient, non-conforming compilers, or for a similar clean-cut scenario.
2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other.
A user needs to have an indication of the branch. Even if it isn't ABI compatible, it still is (at least supposed to be) API compatible. There could be a reason to release 1.y.1 after 1.y+1.0 was released.. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
On Dec 6, 2005, at 1:21 PM, Martin Wille wrote:
I agree, the use of the "1." is questionable. However, we could reserve 2.x.y for a version of Boost that does not contain any workarounds for ancient, non-conforming compilers, or for a similar clean-cut scenario.
I used to think that some day we would get a Boost 2.x that would toss away all of the silly workarounds, but I don't suspect it will ever happen. As compilers drop off the face of the planet, so will their workarounds, but it won't be a big event. "Wow, Boost 2.0, they got rid of junk from 15-year-old compilers!" :) Doug
----- Original Message ----- From: "Doug Gregor" <dgregor@cs.indiana.edu> To: <boost@lists.boost.org> Sent: Wednesday, December 07, 2005 8:15 AM Subject: Re: [boost] on boost version numbers [snip]
I used to think that some day we would get a Boost 2.x that would toss away all of the silly workarounds, but I don't suspect it will ever happen. As compilers drop off the face of the planet, so will their workarounds, but it won't be a big event.
"Wow, Boost 2.0, they got rid of junk from 15-year-old compilers!"
"But wait; there's more! Boost 2.0 has brand new junk for the latest compiler from X!" Workarounds will remain a part of Boost until Boost changes its goals or compilers become perfect implementations of a perfect language specification. Dang.
1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ?
I agree, the use of the "1." is questionable. However, we could reserve 2.x.y for a version of Boost that does not contain any workarounds for ancient, non-conforming compilers, or for a similar clean-cut scenario.
I've the same opinion. (The Apache project also used 1.xx for a very long time; and when they did finally move to 2.xx it was very minor from the typical user's point of view). Darren
Martin Wille wrote:
Stefan Seefeld wrote:
Hi there,
now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously.
I see two issues with the current release numbering scheme:
1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ?
I agree, the use of the "1." is questionable. However, we could reserve 2.x.y for a version of Boost that does not contain any workarounds for ancient, non-conforming compilers, or for a similar clean-cut scenario.
How about reserving 2.x for that day in the distant future when every C++ user can be assumed to have a conforming TR1 implementation? -- Jonathan Turkanis www.kangaroologic.com
On 12/6/05 10:31 AM, "Stefan Seefeld" <seefeld@sympatico.ca> wrote: [SNIP]
2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other.
That next-to-last sentence isn't accurate. We create a new CVS branch when we prepare a x.y.0 release. All subsequent x.y.z releases are based off that branch. This is maintained independently of the HEAD where future x.(y+1) code is developed (before creating a x.(y+1).0 branch). We definitely want to keep those two types of releases distinct. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (12)
-
Darren Cook -
Daryle Walker -
David Abrahams -
Doug Gregor -
John Maddock -
Jonathan Turkanis -
Martin Wille -
Oliver Kullmann -
Sam Partington -
Scott Woods -
Stefan Seefeld -
Thomas Witt