The poll results were suprising. I was responding specifically to the implication that it was suprising
From: David Maisonave that the percentages added to >100%.
I would have thought by now there would be more developers using 7.1/8.0 than 6.0. If Boost decides to stop supporting VC++ 6.0, or reduce support, than they're going to exclude at lot of developers.
Not really. Changing boost library version is probably less painful than changing compiler version, but I wouldn't do either without compelling reason. VC6 users can use boost 1.33.1 (or perhaps even 1.34), and that isn't going to suddenly stop working just because 1.35 doesn't support VC6. Remember that although most developers are using 6.0, they are almost certainly using it on projects which are in maintenance mode. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894
Martin Bonner a écrit :
From: David Maisonave
The poll results were suprising.
I was responding specifically to the implication that it was suprising that the percentages added to >100%.
I would have thought by now there would be more developers using 7.1/8.0 than 6.0. If Boost decides to stop supporting VC++ 6.0, or reduce support, than they're going to exclude at lot of developers.
Not really. Changing boost library version is probably less painful than changing compiler version, but I wouldn't do either without compelling reason.
VC6 users can use boost 1.33.1 (or perhaps even 1.34), and that isn't going to suddenly stop working just because 1.35 doesn't support VC6.
No, but if I know that in boost 1.35, some of the bugs that are pesterring me have been corrected, but I cannot use these fixes, I would have to face one choice : - Upgrading my compiler, that may be inconvenient - Correcting boost myself, that is not why I use an external library - Use only home made stuff, less generic, less adaptable, but that I can support As far as I understand (please tell me if I'm wrong), there is only one supported version of boost. If I discover a bug in boost::xx, next version of boost will have the correction, but the correction will not be back-ported to older versions, even if the bug was already there. This situation if perfectly acceptable, as long as upgrading from one version of boost to the other is low cost. If it requires too many changes in the public interface of boost libs, or even worse, a change of compiler, this becomes troublesome. So, my opinion is that the choice is between : - Support a compiler in boost until it is fully dead, burried, worm-food, not even seable in museums - Complexify the release processus, so that bug-fix releases of old version become commonplace I have no opinion about which of those options would be more time consuming. Best regards, -- Loïc
Loïc Joly <loic.actarus.joly@numericable.fr> writes:
Martin Bonner a écrit :
From: David Maisonave
The poll results were suprising.
I was responding specifically to the implication that it was suprising that the percentages added to >100%.
I would have thought by now there would be more developers using 7.1/8.0 than 6.0. If Boost decides to stop supporting VC++ 6.0, or reduce support, than they're going to exclude at lot of developers.
Not really. Changing boost library version is probably less painful than changing compiler version, but I wouldn't do either without compelling reason.
VC6 users can use boost 1.33.1 (or perhaps even 1.34), and that isn't going to suddenly stop working just because 1.35 doesn't support VC6.
No, but if I know that in boost 1.35, some of the bugs that are pesterring me have been corrected, but I cannot use these fixes, I would have to face one choice : - Upgrading my compiler, that may be inconvenient - Correcting boost myself, that is not why I use an external library - Use only home made stuff, less generic, less adaptable, but that I can support
As far as I understand (please tell me if I'm wrong), there is only one supported version of boost.
What do you mean by "supported?"
If I discover a bug in boost::xx, next version of boost will have the correction, but the correction will not be back-ported to older versions, even if the bug was already there.
Not necessarily so. We could decide to do a 1.33.2 release. -- Dave Abrahams Boost Consulting www.boost-consulting.com
No, but if I know that in boost 1.35, some of the bugs that are pesterring me have been corrected, but I cannot use these fixes, I would have to face one choice : - Upgrading my compiler, that may be inconvenient - Correcting boost myself, that is not why I use an external library - Use only home made stuff, less generic, less adaptable, but that I can support
We haven't been able to upgrade to 1.33 yet but it hasn't been much grief when we have found the odd bug in 1.32 to see if its fixed in the latest and just merge those fixes into our tree, maybe not ideal but not much effort overall. Certainly less effort than writing all the components we use ourselves. my 2c. Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.0/249 - Release Date: 2/02/2006
participants (4)
-
David Abrahams -
Loïc Joly -
Martin Bonner -
Martin Slater