Stability: More on 3 level Boost libraries
Hi, I would like to come back to the 3 level proposition but from a different point of view (stability and quality) 1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets. 2nd level: quite stable Libraries at this level, even if stable, introduce breaking changes from time to time. Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period. 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation. Comments are welcome, _____________________ Vicente Juan Botet Escribá
Vicente Juan Botet Escribá wrote : 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation.
Interesting, does that mean that the review process is separated between the review of "interface and documentation" and a review of the "implementation" (later) ? In that case, I suppose the 'interface and doc' review would be done only if there is at least 1 working implementation -ensuring that the reviewed interface is somewhat usable- ? Best Regards, Pierre Morcello
On 03/23/2010 03:33 PM, Pierre Morcello wrote:
Vicente Juan Botet Escribá wrote : 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation.
Interesting, does that mean that the review process is separated between the review of "interface and documentation" and a review of the "implementation" (later) ?
In that case, I suppose the 'interface and doc' review would be done only if there is at least 1 working implementation -ensuring that the reviewed interface is somewhat usable- ?
I think, as long as Boost is a collection of libraries, only more-or-less complete libraries will be reviewed at all suggested levels (i.e. not abstract interfaces). The difference between the levels is the level of interface stability and the level of requirements for the library to get accepted.
On 23 March 2010 07:36, vicente.botet <vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements. There's also an issue because several libraries have stable and unstable parts. For this to work, we'd have to split them up somehow. I'm not sure how practical that would be. Daniel
----- Original Message ----- From: "Daniel James" <dnljms@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, March 25, 2010 10:06 PM Subject: Re: [boost] Stability: More on 3 level Boost libraries
On 23 March 2010 07:36, vicente.botet <vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements.
Why not to have a stability/quality label. IMO all the core libraries should belong to this level.
There's also an issue because several libraries have stable and unstable parts. For this to work, we'd have to split them up somehow.
I'm not sure how practical that would be.
I'm no sure neither. IMO the main concern is "using libraries that belong only to this level". Best, Vicente
On 03/26/2010 12:06 AM, Daniel James wrote:
On 23 March 2010 07:36, vicente.botet<vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard.
I suggested another division a year (was it?) ago, where I tried to enumerate all libraries while putting them in "core", "math" and "other" categories, as a side effect of trying to prove (or show?) that Boost is mostly about cross-domain programming *and* one specific sector, math (or "scientific programming"), and how strange that particular outshoot seemed to me, and that it could scare some developers away. I still believe in this idea of creating a core layer, where tools that are useful in any (sub) discipline should be put. I.e., not the "stable"/"unstable" division, and especially - as someone pointed out - since that division might cause a bit of emotions on this list... /David On Mar 25, 2010, at 9:22 PM, Andrey Semashev wrote:
On 03/26/2010 12:06 AM, Daniel James wrote:
On 23 March 2010 07:36, vicente.botet<vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi My name is René Eng and I am a team leader in the SD departement. We are programming in C++ and plan to use Boost in the next release of our product, already use some parts already (Boost.Test, Boost.ProgramOptions). I also tried some things from Boost at home, especially Boost.Interprocess. There I did encounter myself the effect that my programs did not compile anymore with a new version of the Boost library. So I look at the '3 level proposal' from a user side of view. While at first glance it seems a good thing, that you can download the stable version and don't worry, I see a lot of dangerous points in there for the boost development community: - You have to maintain 3 sets of the Boost library that are in itself compatible. - What is with bug fixes in the stable version? Wouldn't it take more time until a bug fix could finally be provided in the stable version? - What is if a library should be moved to the stable version, but requires another (version of a) library which is not yet ready for the stable version, or would brake the requirements for stable versions? - I suppose a new library would be available in the stable version only 1 or 2 years after it was released the first time? So if somebody wants to use e.g. the forthcoming Boost Log library, he has to wait a long time. I don't mind that one Boost library uses another (of course: code reuse!). For me as a user, I am happy if the library compiles on my platform and all regression tests run successfully. And i the regression tests cover about 95 % of the code and functions, I am very happy and confident that it will work. If we will use Boost, we will write PIMPL like wrappers anyway, so that changes in the interface of a Boost library will of course require code changes on our side, but only in specific modules, the rest of the application should then be unharmed. Please think through all the advantages and potential problems of maintaining multiple library versions. If you find a good definition that is easy to maintain and really brings advantages to the end user: go ahead. Regards, René P.S. We are dealing with currently 3 different versions of our application used by our customers, so I have some experience with maintaining multiple versions. -- “Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am)” René Descartes
Rene Eng <gemini67 <at> gmail.com> writes:
- You have to maintain 3 sets of the Boost library that are in itself compatible.
I might have missed it, bu t I thought this discussion was not about 3 version of the library. This is definitely, not something I'd support.
- What is with bug fixes in the stable version? Wouldn't it take more time until a bug fix could finally be provided in the stable version?
That's question is unclear to me
- What is if a library should be moved to the stable version, but requires another (version of a) library which is not yet ready for the stable version, or would brake the requirements for stable versions?
That's easy: you can't depend on libraries in development to qualify for "ready for production" status.
- I suppose a new library would be available in the stable version only 1 or 2 years after it was released the first time? So if somebody wants to use e.g. the forthcoming Boost Log library, he has to wait a long time.
Why? It depends on you really. If you are willing to accept possible non-backward compatible changes or willing to stick to this particular version or willing to maintain local copy yourself - you can use any library, even just candidate. Gennadiy
2010/3/26 Gennadiy Rozental <rogeeff@gmail.com>
Rene Eng <gemini67 <at> gmail.com> writes:
- You have to maintain 3 sets of the Boost library that are in itself compatible.
I might have missed it, bu t I thought this discussion was not about 3 version of the library. This is definitely, not something I'd support.
We are talking about three levels of library quality. As an end user, I expect to get a complete set of all Boost libraries of the same level/quality. That's what I mean with three different versions of the library. If that's not the case, then the levels of quality would just be a label applied to a library meaning ... what?
- What is with bug fixes in the stable version? Wouldn't it take more time until a bug fix could finally be provided in the stable version?
That's question is unclear to me
Regarding the explanation above, and then assuming that the bug fix changes the interface in a non-compatible way: The bug fix could not be integrated right away into the stable level of the library, right? Since it would make the library 'not stable' anymore (due to the interface change)?
- What is if a library should be moved to the stable version, but requires another (version of a) library which is not yet ready for the stable version, or would brake the requirements for stable versions?
That's easy: you can't depend on libraries in development to qualify for "ready for production" status.
But that's exactly the point: A new library can only get to the stable version, if all the libraries and their versions it depends on are submitted to the stable version too. Today you submit the library to the next release.
- I suppose a new library would be available in the stable version only 1 or 2 years after it was released the first time? So if somebody wants to use e.g. the forthcoming Boost Log library, he has to wait a long time.
Why? It depends on you really. If you are willing to accept possible non-backward compatible changes or willing to stick to this particular version or willing to maintain local copy yourself - you can use any library, even just candidate.
Yes. So why should Boost need different levels of quality then? If somebody can not accept backward incompatible changes, he simply sticks to the version he was using initially. Otherwise he always uses the new release. Regards, René
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- “Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am)” René Descartes
Rene Eng <gemini67 <at> gmail.com> writes:
We are talking about three levels of library quality. As an end user, I expect to get a complete set of all Boost libraries of the same level/quality. That's what I mean with three different versions of the library.
Boost is not a library.
If that's not the case, then the levels of quality would just be a label applied to a library meaning ... what?
meaning that some boost components are stable, some in development.
The bug fix could not be integrated right away into the stable level of the library, right? Since it would make the library 'not stable' anymore (due to the interface change)?
You can make any *backward compatible* change to the stable library IMO. And you can't make non-backward compatible changes to the stable library period.
But that's exactly the point: A new library can only get to the stable version, if all the libraries and their versions it depends on are submitted to the stable version too. Today you submit the library to the next release.
Each Boost component has it's own life cycle. Presence library in boost release does not make it stable.
- I suppose a new library would be available in the stable version only 1 or 2 years after it was released the first time? So if somebody wants to use e.g. the forthcoming Boost Log library, he has to wait a long time.
Why? It depends on you really. If you are willing to accept possible non-backward compatible changes or willing to stick to this particular version or willing to maintain local copy yourself - you can use any library, even just candidate.
Yes. So why should Boost need different levels of quality then?
User need to know if library is in development of is stable and can make decisions as to usage based on that. Gennadiy
Rene Eng wrote:
2010/3/26 Gennadiy Rozental <rogeeff@gmail.com>
Rene Eng <gemini67 <at> gmail.com> writes:
- You have to maintain 3 sets of the Boost library that are in itself compatible.
I might have missed it, bu t I thought this discussion was not about 3 version of the library. This is definitely, not something I'd support.
We are talking about three levels of library quality. As an end user, I expect to get a complete set of all Boost libraries of the same level/quality.
Every one expect the other must do what we are not able to do :) We are volunteers in the Boost community, and we do our best. Rene Eng wrote:
That's what I mean with three different versions of the library.
If that's not the case, then the levels of quality would just be a label applied to a library meaning ... what?
This was my intention. Just to put a label to a library that could guide the final user about the stability/quality/mai_ntenability of the library Rene Eng wrote:
- What is with bug fixes in the stable version? Wouldn't it take more time until a bug fix could finally be provided in the stable version?
That's question is unclear to me
Regarding the explanation above, and then assuming that the bug fix changes the interface in a non-compatible way: The bug fix could not be integrated right away into the stable level of the library, right? Since it would make the library 'not stable' anymore (due to the interface change)?
I'm not requesting for this level that there are no breaking changes in the interface. I'm just that these change need to be reviewed by the Boost community before been applied, to see if a non breaking solution exists. What you require is not stability, but fix the interfaces. Sorry but I don't think this is a good approach. If something NEEDS to be changed breaking the user interface for a better library, we can not forbid such changes, we need just to manage them. Rene Eng wrote:
- What is if a library should be moved to the stable version, but requires another (version of a) library which is not yet ready for the stable version, or would brake the requirements for stable versions?
That's easy: you can't depend on libraries in development to qualify for "ready for production" status.
But that's exactly the point: A new library can only get to the stable version, if all the libraries and their versions it depends on are submitted to the stable version too. Today you submit the library to the next release.
Rene Eng wrote:
Forget the stable version. There is no a stable version, but stable libraries. All the libraries stable, quite stable and unstable will be released on the same version. Just a library can change its label depending on the criteria.
- I suppose a new library would be available in the stable version only 1 or 2 years after it was released the first time? So if somebody wants to use e.g. the forthcoming Boost Log library, he has to wait a long time.
Why? It depends on you really. If you are willing to accept possible non-backward compatible changes or willing to stick to this particular version or willing to maintain local copy yourself - you can use any library, even just candidate.
Yes. So why should Boost need different levels of quality then? If somebody can not accept backward incompatible changes, he simply sticks to the version he was using initially. Otherwise he always uses the new release.
The fact that a stable library can change its interface if really needed doesn't means that this will occur often, otherwise the library will not be stable, but can occur exceptionally. Best, Vicente -- View this message in context: http://old.nabble.com/Stability%3A-More-on-3-level-Boost-libraries-tp2799714... Sent from the Boost - Dev mailing list archive at Nabble.com.
I was very busy yesterday, but finally here's my reply: 2010/3/26 Vicente Botet Escriba <vicente.botet@wanadoo.fr>
Rene Eng wrote:
That's what I mean with three different versions of the library.
If that's not the case, then the levels of quality would just be a label applied to a library meaning ... what?
This was my intention. Just to put a label to a library that could guide the final user about the stability/quality/mai_ntenability of the library
Okay, that's the point where I misunderstood you. Then of course all the points I mentioned loose their relevance. Sorry for the noise. Regards, René -- “Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am)” René Descartes
Rene Eng wrote:
Hi
My name is René Eng and I am a team leader in the SD departement. We are programming in C++ and plan to use Boost in the next release of our product, already use some parts already (Boost.Test, Boost.ProgramOptions). I also tried some things from Boost at home, especially Boost.Interprocess. There I did encounter myself the effect that my programs did not compile anymore with a new version of the Boost library.
So I look at the '3 level proposal' from a user side of view.
While at first glance it seems a good thing, that you can download the stable version and don't worry, I see a lot of dangerous points in there for the boost development community: - You have to maintain 3 sets of the Boost library that are in itself compatible.
I have never proposed to have 3 versions !!! Best, Vicente -- View this message in context: http://old.nabble.com/Stability%3A-More-on-3-level-Boost-libraries-tp2799714... Sent from the Boost - Dev mailing list archive at Nabble.com.
----- Original Message ----- From: "David Bergman" <David.Bergman@bergmangupta.com> To: <boost@lists.boost.org> Sent: Friday, March 26, 2010 2:27 AM Subject: Re: [boost] Stability: More on 3 level Boost libraries
On Mar 25, 2010, at 9:22 PM, Andrey Semashev wrote:
On 03/26/2010 12:06 AM, Daniel James wrote:
On 23 March 2010 07:36, vicente.botet<vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard. _______________________________________________
I suggested another division a year (was it?) ago, where I tried to enumerate all libraries while putting them in "core", "math" and "other" categories, as a side effect of trying to prove (or show?) that Boost is mostly about cross-domain programming *and* one specific sector, math (or "scientific programming"), and how strange that particular outshoot seemed to me, and that it could scare some developers away.
I missed the thread.
I still believe in this idea of creating a core layer, where tools that are useful in any (sub) discipline should be put. I.e., not the "stable"/"unstable" division, and especially - as someone pointed out - since that division might cause a bit of emotions on this list...
Please, note that this is a vouluntering level. each library author decides on which level its library could be. Best, Vicente
On Mar 26, 2010, at 2:51 AM, vicente.botet wrote:
----- Original Message ----- From: "David Bergman" <David.Bergman@bergmangupta.com>
I still believe in this idea of creating a core layer, where tools that are useful in any (sub) discipline should be put. I.e., not the "stable"/"unstable" division, and especially - as someone pointed out - since that division might cause a bit of emotions on this list...
Please, note that this is a vouluntering level. each library author decides on which level its library could be.
I missed that. That makes more sense than my tacit assumption that we (or a sub set of us) would mark them as more or less stable. Thinking about it a bit more, I would probably prefer a core set, called 'core' for lack of imagination, with a 'general' outshoot, directed at problem solving in any domain, and two other ones, 'sci' and 'other', directed towards specific domains. Yes, 'other' would not be huge... /David
David Bergman wrote:
Thinking about it a bit more, I would probably prefer a core set, called 'core' for lack of imagination, with a 'general' outshoot, directed at problem solving in any domain, and two other ones, 'sci' and 'other', directed towards specific domains. Yes, 'other' would not be huge...
Another important layer in my eyes (now I'm putting on my user cap), is that the boost libraries are clearly meant to be either user-land library (asio, regex, etc) and some are more developer-land library (all the TMP one for example). I think this should also appear in the potential subdivisions.
On 26 March 2010 01:22, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 03/26/2010 12:06 AM, Daniel James wrote:
On 23 March 2010 07:36, vicente.botet<vicente.botet@wanadoo.fr> wrote:
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard.
Your second point doesn't hold since several parts of boost have already made it into the standard. And I don't think it will result in more users. But even it does, it isn't enough of a motivation. Since a library can only be as stable as its dependencies, then the libraries that everyone depends on will need to sign up for this. And I don't think their maintainers are looking for more users (especially Boost.Preprocessor). Daniel
On 26.03.2010 10:50, Daniel James wrote:
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard.
Your second point doesn't hold since several parts of boost have already made it into the standard.
And it what way does it cancel my statement? Perhaps, you mean libraries like Bind or Tuple? These are quite stable for ages.
And I don't think it will result in more users. But even it does, it isn't enough of a motivation. Since a library can only be as stable as its dependencies, then the libraries that everyone depends on will need to sign up for this. And I don't think their maintainers are looking for more users (especially Boost.Preprocessor).
I can't imagine a library author who is not willing his library to be used. That also includes Boost.Preprocessor. That makes me wonder why he wrote the library in the first place.
On 27 March 2010 11:38, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 26.03.2010 10:50, Daniel James wrote:
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard.
Your second point doesn't hold since several parts of boost have already made it into the standard.
And it what way does it cancel my statement? Perhaps, you mean libraries like Bind or Tuple? These are quite stable for ages.
They hadn't agreed to the requirements laid out in the proposal. It requires that the maintainer to have a review for any changes to the public interface changes and to respond to all tickets in a timely fashion. And I don't expect the standards committee are going to insist on those requirements.
I can't imagine a library author who is not willing his library to be used.
I didn't say otherwise. The core libraries are already widely used. Adding extra beaurocracy isn't going to help. Daniel
On 03/27/2010 03:25 PM, Daniel James wrote:
On 27 March 2010 11:38, Andrey Semashev<andrey.semashev@gmail.com> wrote:
On 26.03.2010 10:50, Daniel James wrote:
I can't see why anyone would volunteer for these extra requirements.
To gain more users. Especially in the production environment. Also, this level of stability may be required for inclusion into the C++ standard.
Your second point doesn't hold since several parts of boost have already made it into the standard.
And it what way does it cancel my statement? Perhaps, you mean libraries like Bind or Tuple? These are quite stable for ages.
They hadn't agreed to the requirements laid out in the proposal. It requires that the maintainer to have a review for any changes to the public interface changes and to respond to all tickets in a timely fashion. And I don't expect the standards committee are going to insist on those requirements.
But these requirements were followed, although not formally. For instance, I remember there was a quite exhaustive discussion of whether to break interface of boost::function by removing the allocator from template parameters or not. Fixing this policy explicitly will give a good guideline to other (new) developers of libraries that pretend to be included into the standard.
I can't imagine a library author who is not willing his library to be used.
I didn't say otherwise. The core libraries are already widely used. Adding extra beaurocracy isn't going to help.
It's not about the libraries that are now de-facto "stable". It's about the new libraries that would want to have that label. Your original argument was that there will be no volunteers for reaching the "stable" status of their libraries. I gave you the reason. Am I missing something?
On 27 March 2010 13:43, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Your original argument was that there will be no volunteers for reaching the "stable" status of their libraries. I gave you the reason. Am I missing something?
You gave two reasons. I'm not convinced that either of them are true. I really don't see how this proposal will make any difference to the quality of boost. What I think might be useful would be a simple guideline on how to make interface changes and deprecate old interfaces. But I'll shut up now as this is going nowhere, maybe you'll prove me wrong. Daniel
On Mar 23, 2010, at 3:36 AM, vicente.botet wrote:
Hi,
I would like to come back to the 3 level proposition but from a different point of view (stability and quality)
1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
2nd level: quite stable Libraries at this level, even if stable, introduce breaking changes from time to time. Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period.
3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation.
Comments are welcome,
Vicente, First of all let me say that while I am following this list for quite some time, I still consider myself the quiet person in the background. There have been many threads lately about the current quality, situation, issues etc. with Boost - some with good ideas, some with unnecessary noise and discussions...at least from my point of view. Now, I actually thought about your three-level approach and in general I tend to agree that Boost should incorporate a kind of dividing mechanism to make Boost somewhat easier to use for the "regular" developer. It is certainly questionable what a "regular" developer actually is but for the sake of the argument let's assume someone that does not live and breathe templates, metaprogramming and mind-bending tricks to satisfy the compiler. If this developer sees a library that he actually could put to good use in his daily work, he should be able to use the library within a reasonable timeframe. This comes down to documentation which I do not want to discuss here. However, at the same time, he should be able to make the fair assessment that a newer version of Boost does not break his application due tom some change that may only be indirectly affecting the library he uses. From what I understand, this unfortunately still happens quite often which new releases. Again, 'quite often' is relative since I cannot put a number to it. Based on the above, I like the initial idea of having different levels. What I am unsure about is whether or not diving these levels into stable/quite stable/unstable is a) really clear enough b) really keeps us from having arguments about the category a specific library should go into c) may even make it difficult in general (e.g. what if a library is stable for 2 years but then brakes the interface and thus would be quite stable?) I am usually a big proponent of the simple stable/experimental scheme. In my experience (and view) a library is always experimental in the beginning. Even the best design cannot cover all of the use cases initially. This is actually the phase where a library matures...in versioning speech, I consider these the 0.x releases. However, once a library is flagged 1.0, I do not consider it experimental anymore. At this point, the library is considered stable. If breaking changes have to be introduced, I would rather like to see a "copy' of the library with the new "broken" interface as part of the experimental group again. In other words, the same library exists twice at this time: one in stable, one in experimental. This actually allows user to have the guarantee that a newer release of Boost does not brake their application, they can follow the evolution of the "updated" version of the library and they can even switch to it if they want. Once the new library reaches its point where it gets closer to be considered stable, the original library can marked deprecated. At this point, developer can actually switch over to the new library (still under experimental) and integrate it. After a certain time, the library is then moved from experimental to stable thus replacing the old one. There are certainly variations possible of how to deal with the old and new library etc. but I think you get my initial point. Again, I tend to like simplicity....having two categories that are at the very opposed ends of quality measures seems to be the most obvious in my eyes. Certainly, the policies of these two categories can be further discussed. Well...this has become more lengthy than I anticipated.... ;) Ciao, Andreas
participants (10)
-
Andreas Masur -
Andrey Semashev -
Daniel James -
David Bergman -
Gennadiy Rozental -
Joel Falcou -
Pierre Morcello -
Rene Eng -
Vicente Botet Escriba -
vicente.botet