Deprecation Policy

older
[preprocessor] Link to Boostpro...

Rob Stewart

16 May 2015 16 May '15

5:40 p.m.

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

Show replies by date

Stefan Seefeld

16 May 16 May

9:26 p.m.

On May 16, 2015 2:29 PM, "Rob Stewart" wrote:

...

Some Boost libraries are unmaintained, some are under-maintained, and

others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it.

...

Please consider my initial thoughts below and provide ideas on such a

policy. I will try to capture your ideas and create a policy statement for later review.

...

It would seem obvious that unmaintained libraries should be deprecated,

but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. I think the entire question becomes moot if individual libraries start following their own release schedule. Being maintained then means having regular releases (and thus over time it becomes obvious whether a library is maintained or not). I strongly believe that this is the best way forward, both for the Boost organization as well as individual libraries. Stefan

Rob Stewart

10:23 p.m.

On May 16, 2015 4:26:29 PM CDT, Stefan Seefeld wrote:

...

On May 16, 2015 2:29 PM, "Rob Stewart" wrote:

...
Some Boost libraries are unmaintained, some are under-maintained,

and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it.

...
Please consider my initial thoughts below and provide ideas on such

a policy. I will try to capture your ideas and create a policy statement for later review.

I think the entire question becomes moot if individual libraries start following their own release schedule. Being maintained then means having regular releases (and thus over time it becomes obvious whether a library is maintained or not).

The goal is to offer both for the foreseeable future. (For example, the way my company handles Boost, the monolithic release is more appropriate.) ___ Rob (Sent from my portable computation engine)

Stefan Seefeld

10:43 p.m.

On May 16, 2015 6:31 PM, "Rob Stewart" wrote:

...

On May 16, 2015 4:26:29 PM CDT, Stefan Seefeld

wrote:

...

...
On May 16, 2015 2:29 PM, "Rob Stewart" wrote:

...
Some Boost libraries are unmaintained, some are under-maintained,

and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it.

...
Please consider my initial thoughts below and provide ideas on such

a policy. I will try to capture your ideas and create a policy statement for later review.

I think the entire question becomes moot if individual libraries start following their own release schedule. Being maintained then means having regular releases (and thus over time it becomes obvious whether a library is maintained or not).

The goal is to offer both for the foreseeable future. (For example, the way my company handles Boost, the monolithic release is more appropriate.)

I imagine it's entirety possible to produce a "boost release" (or "distro" to use a term Niall suggested) consisting of all the latest releases of individual boost libraries. You might argue that it's hard to guarantee compatibility among them. But that has been a problem Boost has been plagued with forever: no two boost releases have ever given any guaranty of compatibility. So here again, a little change in policy would very much benefit boost users. Stefan

Peter Dimov

10:52 p.m.

Stefan Seefeld wrote:

...

I imagine it's entirety possible to produce a "boost release" (or "distro" to use a term Niall suggested) consisting of all the latest releases of individual boost libraries.

You might argue that it's hard to guarantee compatibility among them. But that has been a problem Boost has been plagued with forever: no two boost releases have ever given any guaranty of compatibility. So here again, a little change in policy would very much benefit boost users.

I'm not sure I understand. One of the points of doing a Boost release is that the versions of the libraries included in it are compatible with each other. If library X is updated in a way that breaks libraries Y, Z and W, this breakage is (generally) either fixed before the release or X is rolled back. How would losing this very much benefit users is something that's not immediately obvious to me.

charleyb123 .

10:54 p.m.

...

Rob sayeth:

, Stefan respondeth:

...

I imagine it's entirety possible to produce a "boost release" (or "distro" to use a term Niall suggested) consisting of all the latest releases of individual boost libraries.

You might argue that it's hard to guarantee compatibility among them. But that has been a problem Boost has been plagued with forever: no two boost releases have ever given any guaranty of compatibility. So here again, a little change in policy would very much benefit boost users.

Stefan

This is a very interesting idea: The concept of a "Distribution". I could see something like: (a)- Boost "Networking/IPC" distribution (b)- Boost "Embedded" distribution (supporting Beaglebone or specific platform) (c)- Boost "Template Meta-Programming" distribution (requires C++14) (d)- Boost "Everything" Distribution (what we have now) (e)- etc.

Stefan Seefeld

17 May 17 May

1:08 a.m.

On May 16, 2015 6:55 PM, "charleyb123 ." wrote:

...

...
Rob sayeth:

,

Stefan respondeth:

...
I imagine it's entirety possible to produce a "boost release" (or

"distro"

...

...
to use a term Niall suggested) consisting of all the latest releases of individual boost libraries.

You might argue that it's hard to guarantee compatibility among them. But that has been a problem Boost has been plagued with forever: no two boost releases have ever given any guaranty of compatibility. So here again, a little change in policy would very much benefit boost users.

Stefan

This is a very interesting idea: The concept of a "Distribution".

I could see something like:

[...] Indeed an interesting thought though a) yet another responsibility for boost (caring about deployment) and b) quite tangential to the original point which was about figuring out whether a given library was maintained or not. To reiterate my proposal: Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime). Stefan

Vladimir Prus

18 May 18 May

6:56 a.m.

On 5/17/2015 4:08 AM, Stefan Seefeld wrote:

...

Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime).

Stefan, could we start by agreeing that not every set of C++-level components will actually benefit, in a cost/benefit sense, from separate development and release? Say, Qt has a few libraries, but has monolithic release. It might be possible to permit QtGui 5.N+1 to work with QtCore 5.N, but the effort and alternative cost of doing so would greatly exceed any benefit. If we agree on that, then maybe it would be better to propose specific boost libraries that should be released individually, do that, and see whether users appreciate the benefit? That seems more practical than a blanket statement about all boost libraries. Thanks, Volodya

Stefan Seefeld

10:29 p.m.

On 18/05/15 02:56 AM, Vladimir Prus wrote:

...

On 5/17/2015 4:08 AM, Stefan Seefeld wrote:

...
Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime).

Stefan,

could we start by agreeing that not every set of C++-level components will actually benefit, in a cost/benefit sense, from separate development and release? Say, Qt has a few libraries, but has monolithic release. It might be possible to permit QtGui 5.N+1 to work with QtCore 5.N, but the effort and alternative cost of doing so would greatly exceed any benefit.

Sure, fair enough.

...

If we agree on that, then maybe it would be better to propose specific boost libraries that should be released individually, do that, and see whether users appreciate the benefit? That seems more practical than a blanket statement about all boost libraries.

OK, that's a good suggestion. So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on. Any thoughts on that ? Stefan -- ...ich hab' noch einen Koffer in Berlin...

Vladimir Prus

20 May 20 May

7:21 p.m.

On 19.05.2015 01:29, Stefan Seefeld wrote:

...

On 18/05/15 02:56 AM, Vladimir Prus wrote:

...
On 5/17/2015 4:08 AM, Stefan Seefeld wrote:

...
Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime).

Stefan,

could we start by agreeing that not every set of C++-level components will actually benefit, in a cost/benefit sense, from separate development and release? Say, Qt has a few libraries, but has monolithic release. It might be possible to permit QtGui 5.N+1 to work with QtCore 5.N, but the effort and alternative cost of doing so would greatly exceed any benefit.

Sure, fair enough.

Good, thanks!

...

...
If we agree on that, then maybe it would be better to propose specific boost libraries that should be released individually, do that, and see whether users appreciate the benefit? That seems more practical than a blanket statement about all boost libraries.

OK, that's a good suggestion. So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on.

Any thoughts on that ?

That's certainly sufficiently local in scope that it could be done. The only concern is that I'm not sure there are many users who need very current Boost.Python, and older Boost. Do you feel there is a demand? Or it's merely that you'll find it more convenient for yourself? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Stefan Seefeld

7:37 p.m.

On 20/05/15 03:21 PM, Vladimir Prus wrote:

...

On 19.05.2015 01:29, Stefan Seefeld wrote:

...
So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on.

Any thoughts on that ?

That's certainly sufficiently local in scope that it could be done.

The only concern is that I'm not sure there are many users who need very current Boost.Python, and older Boost. Do you feel there is a demand? Or it's merely that you'll find it more convenient for yourself?

I very strongly believe that modularizing Boost will be beneficial for everyone. I'm offering to do the first (experimental) steps with Boost.Python in the hopes that this demonstrates the usefulness to other library authors and maintainers who will then follow the same path. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

10:43 p.m.

Stefan Seefeld wrote:

...

...
...
So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on. ... I very strongly believe that modularizing Boost will be beneficial for everyone. I'm offering to do the first (experimental) steps with Boost.Python in the hopes that this demonstrates the usefulness to other library authors and maintainers who will then follow the same path.

I'm not sure I understand what you want to do. When you say "decoupling", what do you mean? Moving to a separate release schedule, or making Boost.Python not depend on other Boost libraries? What is your plan?

Stefan Seefeld

11:07 p.m.

On 20/05/15 06:43 PM, Peter Dimov wrote:

...

Stefan Seefeld wrote:

...
...
...
So, as I'm trying to get back into Boost.Python, I'm considering decoupling that from the rest of Boost. I think this is an obvious first candidate, notably because it's a substantial library (not header-only) that few other Boost components depend on. ... I very strongly believe that modularizing Boost will be beneficial for everyone. I'm offering to do the first (experimental) steps with Boost.Python in the hopes that this demonstrates the usefulness to other library authors and maintainers who will then follow the same path.

I'm not sure I understand what you want to do. When you say "decoupling", what do you mean? Moving to a separate release schedule, or making Boost.Python not depend on other Boost libraries? What is your plan?

1) Allow Boost.Python to build stand-alone, i.e. against pre-installed Boost dependencies. 2) Release Boost.Python independently from the rest of Boost. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

11:13 p.m.

Stefan Seefeld wrote:

...

1) Allow Boost.Python to build stand-alone, i.e. against pre-installed Boost dependencies. 2) Release Boost.Python independently from the rest of Boost.

This seems doable, but I wonder how would you handle Boost.Build. Require a preinstalled one? Use another build system? Or ship Boost.Build in your release?

Stefan Seefeld

11:21 p.m.

On 20/05/15 07:13 PM, Peter Dimov wrote:

...

Stefan Seefeld wrote:

...
1) Allow Boost.Python to build stand-alone, i.e. against pre-installed Boost dependencies. 2) Release Boost.Python independently from the rest of Boost.

This seems doable, but I wonder how would you handle Boost.Build. Require a preinstalled one? Use another build system? Or ship Boost.Build in your release?

Boost.Build is a prerequisite just as any other, and I have no (immediate) plans to change that. So as long as Boost.Build is available on the computer, users should be able to build Boost.Python with it. (And I certainly don't want to bundle Boost.Build with Boost.Python. In fact, I believe Boost.Build would be the obvious first choice to decouple fully from the rest of Boost, and release separately, but that's not my call to make.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

11:33 p.m.

Stefan Seefeld wrote:

...

In fact, I believe Boost.Build would be the obvious first choice to decouple fully from the rest of Boost, and release separately, but that's not my call to make.

Like this? https://github.com/boostorg/build/releases/tag/2014.10 :-)

Stefan Seefeld

11:39 p.m.

On 20/05/15 07:33 PM, Peter Dimov wrote:

...

Stefan Seefeld wrote:

...
In fact, I believe Boost.Build would be the obvious first choice to decouple fully from the rest of Boost, and release separately, but that's not my call to make.

Like this?

https://github.com/boostorg/build/releases/tag/2014.10

:-)

Yes, like this. But I think for this really to work efficiently it needs to be taken out of regular Boost releases, as otherwise people will continue using the latter. (And notably, packagers who build binary packages (for example for all the various Linux distributions) will continue building boost-build packages out of Boost releases, rather than the stand-alone Boost.Build releases, which may well lead to confusion and even discrepancies. (just think about tracking version numbers for compatibility...) Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

11:59 p.m.

Stefan Seefeld wrote:

...

On 20/05/15 07:33 PM, Peter Dimov wrote:

...
Stefan Seefeld wrote:

...
In fact, I believe Boost.Build would be the obvious first choice to decouple fully from the rest of Boost, and release separately, but that's not my call to make.

Like this?

https://github.com/boostorg/build/releases/tag/2014.10

:-)

Yes, like this. But I think for this really to work efficiently it needs to be taken out of regular Boost releases, as otherwise people will continue using the latter. (And notably, packagers who build binary packages (for example for all the various Linux distributions) will continue building boost-build packages out of Boost releases, rather than the stand-alone Boost.Build releases, which may well lead to confusion and even discrepancies.

I see a slight problem here though (one which you will also encounter when you make a standalone release). You have to have a Jamroot somewhere in your release. Let's say you take the current Boost and delete everything except libs/python, Jamroot, boost-build.jam and boostcpp.jam. You do b2 --boost-build=/usr/local/boost-build (or whatever, I don't know where distributions install Boost.Build), but it probably won't work. The reasons it won't is that (a) Jamroot in Boost 1.58 _probably_ requires Boost.Build 1.58, or perhaps 1.57 at minimum, and you may have an earlier version, and (b) it currently includes a project from Boost.Config: use-project /boost/architecture : libs/config/checks/architecture ; which it probably needs to implement the architecture feature. That is, Boost.Build itself is absolutely standalone, but not all Boost.Build releases will work with a given Boost release. Which is very likely why distributions package Boost.Build from the Boost release, instead of using a standalone release - it's guaranteed to be compatible.

Stefan Seefeld

21 May 21 May

12:46 a.m.

On 20/05/15 07:59 PM, Peter Dimov wrote:

...

That is, Boost.Build itself is absolutely standalone, but not all Boost.Build releases will work with a given Boost release.

Which is very likely why distributions package Boost.Build from the Boost release, instead of using a standalone release - it's guaranteed to be compatible.

I understand. So if Boost.Build were to released stand-alone, dependent packages (such as the fictional Boost-without-BB or Boost.Python) would have to test what (earliest) version of Boost.Build will work (assuming future Boost.Build releases will remain compatible, which is another serious concern), and then document that requirement appropriately. This is all doable, and other package have done this forever. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Rene Rivera

3:18 a.m.

On Wed, May 20, 2015 at 6:59 PM, Peter Dimov wrote:

...

Stefan Seefeld wrote:

...
...
Stefan Seefeld wrote:

...
In fact, I believe Boost.Build would be the obvious first choice to >> decouple fully from the rest of Boost, and release separately, but >>

On 20/05/15 07:33 PM, Peter Dimov wrote: that's not my call to make.

...
Like this?

https://github.com/boostorg/build/releases/tag/2014.10

:-)

Yes, like this. But I think for this really to work efficiently it needs to be taken out of regular Boost releases, as otherwise people will continue using the latter. (And notably, packagers who build binary packages (for example for all the various Linux distributions) will continue building boost-build packages out of Boost releases, rather than the stand-alone Boost.Build releases, which may well lead to confusion and even discrepancies.

I see a slight problem here though (one which you will also encounter when you make a standalone release). You have to have a Jamroot somewhere in your release. Let's say you take the current Boost and delete everything except libs/python, Jamroot, boost-build.jam and boostcpp.jam. You do

b2 --boost-build=/usr/local/boost-build

It would just be: b2 As BB knows how to automatically find, and check for version compatibility, a system installed BB. (or whatever, I don't know where distributions install Boost.Build), but it

...

probably won't work. The reasons it won't is that (a) Jamroot in Boost 1.58 _probably_ requires Boost.Build 1.58, or perhaps 1.57 at minimum, and you may have an earlier version, and

BB is actually fairly flexible when it comes to versions as it's something we've had to deal with for more than a decade now. Flexible to the point of it having some internal alternate implementations of stuff based on the BB vs b2/bjam versions.

...

(b) it currently includes a project from Boost.Config:

use-project /boost/architecture : libs/config/checks/architecture ;

which it probably needs to implement the architecture feature.

That is, Boost.Build itself is absolutely standalone, but not all Boost.Build releases will work with a given Boost release.

Right. But it's something that is a known issue and has solutions (some better than others). And if it's something really important to deal with we can come up with even better solutions (even going back to the traditional jam mode of bundling the entire thing into the exec). Which is very likely why distributions package Boost.Build from the Boost

...

release, instead of using a standalone release - it's guaranteed to be compatible.

Because it is easier to maintain is indeed why Volodya decided to go back to including BB in Boost "directly". But it's not terribly hard to make everything work separately. And as I've mentioned in another thread (with Stefan) I build a personal project that uses Boost and uses Cinder (which uses a bunch of Boost) in a totally modular manner. I.e. I get each Boost lib individually, and only the ones I need to build. And with some BB magic I can specify inter-library dependencies and have it all build correctly in any variation I want (without the variant tagging though). Hence, it's achievable. It's just a matter of knowing the specific requirements and implementing the support in BB. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Peter Dimov

11:04 a.m.

Rene Rivera wrote:

...

And as I've mentioned in another thread (with Stefan) I build a personal project that uses Boost and uses Cinder (which uses a bunch of Boost) in a totally modular manner. I.e. I get each Boost lib individually, and only the ones I need to build. And with some BB magic I can specify inter-library dependencies and have it all build correctly in any variation I want (without the variant tagging though).

This works for me (or rather, worked for me last time I tried) right now out of the box, without any additional BB magic. That is, if I put into a directory Jamroot, boost-build.jam, boostcpp.jam, tools/build, libs/this and libs/that, it all works. This is what bpm does (that is, it downloads those things into a directory). But it's not what Stefan wants. He wants to be able to download just libs/python on a, say, Ubuntu system with Boost 1.55 installed, then build it against the installed Boost components with the installed Boost.Build. Maybe this works too, I haven't checked.

Rene Rivera

1:57 p.m.

On Thu, May 21, 2015 at 6:04 AM, Peter Dimov wrote:

...

Rene Rivera wrote:

...
And as I've mentioned in another thread (with Stefan) I build a personal project that uses Boost and uses Cinder (which uses a bunch of Boost) in a totally modular manner. I.e. I get each Boost lib individually, and only the ones I need to build. And with some BB magic I can specify inter-library dependencies and have it all build correctly in any variation I want (without the variant tagging though).

This works for me (or rather, worked for me last time I tried) right now out of the box, without any additional BB magic. That is, if I put into a directory Jamroot, boost-build.jam, boostcpp.jam, tools/build, libs/this and libs/that, it all works. This is what bpm does (that is, it downloads those things into a directory).

And to be clear :-) What I'm saying is that I can do that without having to add the Jamroot, boost-build.jam, boostcpp.jam, etc. from Boost. And without having to follow the Boost dir structure at all. Obviously I add my own Jamroot and boost-build.jam for my own project. But it's not what Stefan wants. He wants to be able to download just

...

libs/python on a, say, Ubuntu system with Boost 1.55 installed, then build it against the installed Boost components with the installed Boost.Build.

...

Maybe this works too, I haven't checked.

It doesn't yet (although I think he has it somewhat kludged to work). But it's not far from working. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Peter Dimov

18 May 18 May

11 a.m.

Stefan Seefeld wrote:

...

To reiterate my proposal:

Let's try to modularize boost libraries to the point where they can be developed, built, and released individuality. Let's try to provide backwards compatibility guarantees such that users may swap in new versions of a library without fearing failures (either at compile time nor runtime).

To repeat myself, I don't think that people calling for independent library releases appreciate the hidden benefits of the current release approach. These are taken for granted and only the problems are visible. It obviously depends on the library, but many Boost libraries are highly interconnected. It will not be any fun if every user had to discover for himself that for X 4.1, he needs to use Y 2.7 or higher but lower than 3.0, which requires X 5.2 or above. As for providing ironclad backward compatibility guarantees, this, too, is somewhat optimistic. Based on my experience - which may be somewhat skewed - I can quite confidently state that there is no change, however minor, that doesn't break someone's code. I am no fan of monolithic releases, but we need to have a clear understanding of what they bring to the table. Specifically, the current release approach is a guarantee that the library versions in a release have been tested with one another. It serves as an integration test, complementing each library's unit tests. Breaking changes in a Boost library are often discovered when another Boost library breaks. That said, I do think that releases should be made less monolithic. It should indeed be possible for people to swap in a new version of some library. This requires libraries to be confined to their own directory in libs/ (as they are when using Boost from Git.) Specifically, this would entail retaining the include/ directories, doing "b2 headers" on install, and decentralizing the documentation. The virtual include directory created by "b2 headers" is going to inconvenience people who like to put the whole boost-1.x.y/ into version control, but such is life. On the upside, more modular releases ought to be easier to do.

Rob Stewart

17 May 17 May

1:36 a.m.

On May 16, 2015 6:54:38 PM EDT, "charleyb123 ." wrote:

...

...
Rob sayeth:

,

Stefan respondeth:

...
I imagine it's entirety possible to produce a "boost release" (or "distro" to use a term Niall suggested) consisting of all the latest releases of individual boost libraries.

This is a very interesting idea: The concept of a "Distribution".

I could see something like:

(a)- Boost "Networking/IPC" distribution

(b)- Boost "Embedded" distribution (supporting Beaglebone or specific platform)

(c)- Boost "Template Meta-Programming" distribution (requires C++14)

(d)- Boost "Everything" Distribution (what we have now)

(e)- etc.

Whether that has merit is a separate matter. (Note that such an idea will only ever come to fruition if someone does the work.) ___ Rob (Sent from my portable computation engine)

Brian Ravnsgaard Riis

18 May 18 May

5:13 a.m.

Den 16-05-2015 kl. 23:26 skrev Stefan Seefeld:

...

I think the entire question becomes moot if individual libraries start following their own release schedule. Being maintained then means having regular releases (and thus over time it becomes obvious whether a library is maintained or not).

This might suggest that an old library gets removed from the boost release, even though it may be a small piece that Just Works. I believe that was one of Rob's bullets as well. Or did I misunderstand you? /Brian

Michael Ainsworth

6:43 a.m.

New subject: Environment Variables Library?

After asking a question on StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables? http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs-...

Rob Stewart

8:37 a.m.

New subject: Environment Variables Library?

On May 18, 2015 2:43:57 AM EDT, Michael Ainsworth wrote:

...

After asking a question on StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables?

http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs-...

Please start a new thread rather than replying to an existing thread with a new subject. ___ Rob (Sent from my portable computation engine)

Stefan Seefeld

10:33 p.m.

On 18/05/15 01:13 AM, Brian Ravnsgaard Riis wrote:

...

Den 16-05-2015 kl. 23:26 skrev Stefan Seefeld:

...
I think the entire question becomes moot if individual libraries start following their own release schedule. Being maintained then means having regular releases (and thus over time it becomes obvious whether a library is maintained or not).

This might suggest that an old library gets removed from the boost release, even though it may be a small piece that Just Works. I believe that was one of Rob's bullets as well.

Or did I misunderstand you?

Yes, because I'm not suggesting to remove anything. A library that doesn't get updated simply stays at the last release. Of course, if we move to a modular model where a "full boost" release would be superseded by a small "boost core" release and many separate boost library releases, we'd have to do one other release of the above, so it remains visible. My assumption really was that a library could remain useful even without any update, and the release date will indicate when it was last changed. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Arthur Gruzauskas

17 May 17 May

1:23 a.m.

On Sat, 16 May 2015 11:40:30 AM Rob Stewart wrote:

...

Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___

I remember when first looking at Boost some years ago, it was a delight to see so many interesting libraries, I was like a kid in a candy store. However, there is no easy way of telling which libraries are active and which are unmaintained. Do I invest time in learning and using a library that is unmaintained, or do I adapt to a newer library that is close enough to be useful and more likely to be updated with time? The library documentation lets you view the list of libraries in several ways, could one of those ways also sort into them into well maintained, unmaintained but working, and unmaintained (just an example)? It is fairly low tech, but easy for users. That also defers the decision to dump an old library, as it is there for those with legacy systems or the curious, down at the bottom of the page. I would leave it there till it doesnt compile or has major unfixed errors. That is also a judgement call, but is less critical as it is at the bottom of the page. Arthur

John Maddock

9 a.m.

...

However, there is no easy way of telling which libraries are active and which are unmaintained. Do I invest time in learning and using a library that is unmaintained, or do I adapt to a newer library that is close enough to be useful and more likely to be updated with time? That's a good point, to a first approximation you could look to see when

the last commit to master was (not very user friendly of course), I wonder if that information could be automated? Or would it be swamped by admin changes that aren't "real" releases? In fact the more I think about this, the harder it is to tell, I bet there are many libraries that are mature enough that they get little or no maintenance - and frankly don't really need it. They worked fine yesterday, they'll work fine tomorrow. C++11/14/17 isn't going to change that. Perhaps in some cases move-aware constructors would be a useful addition, but that may be all. You could look at Trac to see if there are large numbers of open issues - but you know what, old libraries accumulate "unfixable cruft". It doesn't necessarily make them broken/unmaintained/obsolete. Speaking only for myself, I generally prefer to leave these open rather than gratuitously close as "won't fix", even though they will *probably* never be fixed. Maybe we need some kind of survey, say 2 libraries a week, skip any that are obviously maintained and then ask the questions: * Is the maintainer still around? * Does it matter - is it accumulating issues? * Does anything need doing to bring it into C++11/14 land? * Has it been obsoleted - which is to say, does it make sense to use this in new code? I'll finish by pointing out one lib that fails on the last question - call_traits - in fact I might go off and submit a documentation PR now... Thinking out loud yours, John.

Vicente J. Botet Escriba

8:31 p.m.

Le 17/05/15 11:00, John Maddock a écrit :

...

...
However, there is no easy way of telling which libraries are active and which are unmaintained. Do I invest time in learning and using a library that is unmaintained, or do I adapt to a newer library that is close enough to be useful and more likely to be updated with time? That's a good point, to a first approximation you could look to see when the last commit to master was (not very user friendly of course), I wonder if that information could be automated? Or would it be swamped by admin changes that aren't "real" releases?

In fact the more I think about this, the harder it is to tell, I bet there are many libraries that are mature enough that they get little or no maintenance - and frankly don't really need it. They worked fine yesterday, they'll work fine tomorrow. C++11/14/17 isn't going to change that. Perhaps in some cases move-aware constructors would be a useful addition, but that may be all.

You could look at Trac to see if there are large numbers of open issues - but you know what, old libraries accumulate "unfixable cruft". It doesn't necessarily make them broken/unmaintained/obsolete. Speaking only for myself, I generally prefer to leave these open rather than gratuitously close as "won't fix", even though they will *probably* never be fixed.

Next follows some reports that could help: Open Bug count by Component - https://svn.boost.org/trac/boost/report/24 Newest closed ticket by component - https://svn.boost.org/trac/boost/report/40 Oldest modified active ticket by component - https://svn.boost.org/trac/boost/report/39 As any figures, these are just figures. Common sense is needed.

...

Maybe we need some kind of survey, say 2 libraries a week, skip any that are obviously maintained and then ask the questions: Good idea.

* Is the maintainer still around? * Does it matter - is it accumulating issues? * Does anything need doing to bring it into C++11/14 land? * Has it been obsoleted - which is to say, does it make sense to use this in new code?

This report Newest closed ticket by component - https://svn.boost.org/trac/boost/report/40?sort=modified&asc=1&page=1 gives a good hint of libraries that could be unmaintained. A library that don't have new fixed issues and that have a lot of them could be a candidate that merits to be inspected. Vicente

Vladimir Prus

18 May 18 May

6:38 a.m.

On 5/17/2015 11:31 PM, Vicente J. Botet Escriba wrote:

...

This report

Newest closed ticket by component - https://svn.boost.org/trac/boost/report/40?sort=modified&asc=1&page=1

gives a good hint of libraries that could be unmaintained. A library that don't have new fixed issues and that have a lot of them could be a candidate that merits to be inspected.

There's something wrong with that report. The 'jamboost' component has been removed quite some time ago; at least it does not show up in regular list of components for a query. Same for 'configure script' and 'bjam'. Possibly whatever SQL query is used need to exclude deleted compoments, or something like that? - Volodya

Vladimir Prus

6:43 a.m.

On 5/17/2015 12:00 PM, John Maddock wrote:

...

You could look at Trac to see if there are large numbers of open issues - but you know what, old libraries accumulate "unfixable cruft". It doesn't necessarily make them broken/unmaintained/obsolete. Speaking only for myself, I generally prefer to leave these open rather than gratuitously close as "won't fix", even though they will *probably* never be fixed.

That's very true indeed. In theory, closing issues as wontfix will lead to more clarity, but in practice submitter often gets unhappy, and can easily argue that wontfix resolution is just a sign of "undermaintenance". - Volodya

Gavin Lambert

2:54 a.m.

On 17/05/2015 05:40, Rob Stewart wrote:

...

Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries.

Just a note that in some cases this is not clear-cut either -- for example Boost.SmartPtr contains more functionality than the similarly-named types in the standard. In many cases you don't really care and can use either interchangeably, but if you're depending on one of the extended features in the Boost version then it would be annoying if this were considered deprecated.

3478

Age (days ago)

3483

Last active (days ago)

List overview

Download

33 comments

12 participants

participants (12)

Arthur Gruzauskas
Brian Ravnsgaard Riis
charleyb123 .
Gavin Lambert
John Maddock
Michael Ainsworth
Peter Dimov
Rene Rivera
Rob Stewart
Stefan Seefeld
Vicente J. Botet Escriba
Vladimir Prus