It is generally known within the community that some of the libraries in Boost are not being properly maintained: issues pile up without a prompt (or any) response from the nominal maintainers, eroding the libraries' usefulness and, ultimately, their viability. There are a number of stalwart contributors (Peter Dimov, Andrey Semashev, and others) who work to make sure CI tests stay green throughout the project, but beyond that they can't possibly address outstanding issues and evolution requests for all libraries. Any initiative to try to remedy this situation begins with identifying its true extent. My colleagues at the FSC and I have gone through all Boost libraries and identified those that we regard as unmaintained, as evidenced by the presence of many important issues that go unresolved without anyone addressing them. This is the list: accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap Any such assessment is a little fuzzy by definition, so the cutoff point for what's considered maintained or not is subject to discussion. I'd like to request your feedback: * If you think some entry in this list should be removed (because you're the maintainer or you know the library is actually maintained and we got it wrong), please say so. * Conversely, tell us if you feel some Boost library not in the list should be included. * Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries. For starters, unmaintained libraries could be labeled as such on the website to attract people potentially interested in taking over (and to warn potential users about long-term adoption risks). Thank you! Best, Joaquín M López Muñoz Fiscal Sponsorship Committee
May be considered offtopic so my apologies, but does foreach need maintaining? IIRC it is is macro magic not needed for past 15 years, since C++11. On Tue, 20 Oct 2026 at 18:26, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:
It is generally known within the community that some of the libraries in Boost are not being properly maintained: issues pile up without a prompt (or any) response from the nominal maintainers, eroding the libraries' usefulness and, ultimately, their viability. There are a number of stalwart contributors (Peter Dimov, Andrey Semashev, and others) who work to make sure CI tests stay green throughout the project, but beyond that they can't possibly address outstanding issues and evolution requests for all libraries.
Any initiative to try to remedy this situation begins with identifying its true extent. My colleagues at the FSC and I have gone through all Boost libraries and identified those that we regard as unmaintained, as evidenced by the presence of many important issues that go unresolved without anyone addressing them. This is the list:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap
Any such assessment is a little fuzzy by definition, so the cutoff point for what's considered maintained or not is subject to discussion. I'd like to request your feedback:
* If you think some entry in this list should be removed (because you're the maintainer or you know the library is actually maintained and we got it wrong), please say so. * Conversely, tell us if you feel some Boost library not in the list should be included. * Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries. For starters, unmaintained libraries could be labeled as such on the website to attract people potentially interested in taking over (and to warn potential users about long-term adoption risks).
Thank you!
Best,
Joaquín M López Muñoz Fiscal Sponsorship Committee
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/O5IU5L3U...
This is the list:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap
Should we think about retiring and removing libraries for some of these? For example: foreach and tuple should have been replaced C++11 and scope replaces scope_exit. Matt
Many thanks to the Fiscal Sponsorship Committee for putting this together. I am not against retiring some libraries, but isn't this conditional on removing dependencies on it throughout the Boost superproject? This could end up requiring significant work, especially if unmaintained libraries depend on it. Best wishes, Arnaud
I am not against retiring some libraries, but isn't this conditional on removing dependencies on it throughout the Boost superproject? This could end up requiring significant work, especially if unmaintained libraries depend on it.
The recent removal of Boost.Static_Assert shows that it is possible. I would think that work would be more valuable than maintaining something that is purely for legacy usage. Matt
The recent removal of Boost.Static_Assert shows that it is possible. I would think that work would be more valuable than maintaining something that is purely for legacy usage.
Note that some libraries might need more than deprecation notices however, that's a something I just wanted to note. Best, Amlal
Yes I agree, it’s possible and valuable. Although any unmaintained library propagating retired boost types through public interfaces (e.g boost.tuple) would delay retirement by possibly many deprecation cycles ? Best wishes, Arnaud Becheler
Matt Borland wrote:
The recent removal of Boost.Static_Assert shows that it is possible. I would think that work would be more valuable than maintaining something that is purely for legacy usage.
We didn't remove StaticAssert, we moved it to Config. Everything using it (that is, everything including <boost/static_assert.hpp>) still compiles.
Arnaud Becheler wrote:
Many thanks to the Fiscal Sponsorship Committee for putting this together.
I am not against retiring some libraries, but isn't this conditional on removing dependencies on it throughout the Boost superproject? This could end up requiring significant work, especially if unmaintained libraries depend on it.
You can see what depends on Foreach here https://pdimov.github.io/boostdep-report/develop/foreach.html#reverse-depend... and on Tuple, here https://pdimov.github.io/boostdep-report/develop/tuple.html#reverse-dependen...
Arnaud Becheler wrote:
You can see what depends on Foreach here and on Tuple, here
Thank you Peter. Wouldn’t Boost Dep report be possibly blind to tests or examples in various Boost repos that would break after retirement ?
Yes, the report doesn't show test or example dependencies.
On 20 Oct 2026 19:44, Matt Borland via Boost wrote:
Should we think about retiring and removing libraries for some of these? For example: foreach and tuple should have been replaced C++11 and scope replaces scope_exit.
Unless a library is entirely non-functional, I don't see how removing it would help anyone. It would break its users, it wouldn't release any Boost maintainers (since the library is unmaintained). Some of these seemingly obsolete libraries offer unique features or provide support for older C++ versions.
Unless a library is entirely non-functional, I don't see how removing it would help anyone.
I think different people are optimizing along different axes: 1. Maintenance allocation. Joaquin's original goal was to list unmaintained libraries so we could optimize maintenance coverage/signaling and redirect potential maintainers to candidate libraries. When maintainers are scarce, deciding which libraries to maintain is strategic, and very old libraries with a standard equivalent within Boost's baseline are natural candidates for the bottom of that list. 2. Discoverability. As an ecosystem, Boost wants newcomers to find what they need. Presenting 165 libraries, with no signal about which ones are current, to someone who is 25 years old and has always had C++11 is not a great first impression. When a user hits an unmaintained library with open bugs and no response, the cost is not limited to that library: it erodes confidence in Boost as a whole. 3. Cross repository cost. Anyone involved in cross repository work knows a library is never completely unmaintained, and the sheer number of libraries is hard to get through. Rene spent years going through every library to make Boost build modularly ( https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc), often having to fix obsolete CI setups, broken compilers, and so on (I helped him with 3/165 and it was already painful ahah). An obsolete library does not exist in a vacuum: it must coexist with the others, and someone pays for it, either in maintainer time or in user frustration over features that are slow to arrive (modular builds being the obvious example - several French people complained about it). But as Rene and Vinnie mentioned, the first step is to remove internal use anyway, which should take a few years. And to begin somewhere, we should at least have some priority ranking of the libs Joaquin listed, be it for candidate maintainers matching or for planning internal use removal steps.
Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries.
Right now, the path "this lib is unmaintained" -> “i'm interested” -> “I'm maintainer” is hard (impossible?) to see from the outside. A clear handover process could help: a clickable button on the Boost website that filters unmaintained libs, who to contact, how ownership gets transferred, a trial period as co maintainer, and an onboarding document. Best wishes, Arnaud Becheler
Joaquin, et al. Agree that that there is a lot of value to be had in dividing and pruning the number of libraries in Boost. Maintained/unmaintained is not the only division that would help. There is also "currently active" vs "stable/inactive" and "consumed into the Standard in whole or major part" vs "unique to Boost". With the help of AI and digging into docs I came up with the following table - mostly focusing on the uniqueness of the library and its' activity status - it's a work in progress but the idea is to help potential new users identify current focus and directions: https://www.boost.org/doc/user-guide/library-table.html I am kind of suggesting that "Uniqueness to Boost" is the top priority for potential and current users. best - Peter On Tue, Oct 20, 2026 at 11:28 AM Arnaud Becheler via Boost < boost@lists.boost.org> wrote:
Unless a library is entirely non-functional, I don't see how removing it would help anyone.
I think different people are optimizing along different axes:
1. Maintenance allocation. Joaquin's original goal was to list unmaintained libraries so we could optimize maintenance coverage/signaling and redirect potential maintainers to candidate libraries. When maintainers are scarce, deciding which libraries to maintain is strategic, and very old libraries with a standard equivalent within Boost's baseline are natural candidates for the bottom of that list.
2. Discoverability. As an ecosystem, Boost wants newcomers to find what they need. Presenting 165 libraries, with no signal about which ones are current, to someone who is 25 years old and has always had C++11 is not a great first impression. When a user hits an unmaintained library with open bugs and no response, the cost is not limited to that library: it erodes confidence in Boost as a whole.
3. Cross repository cost. Anyone involved in cross repository work knows a library is never completely unmaintained, and the sheer number of libraries is hard to get through. Rene spent years going through every library to make Boost build modularly ( https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc ), often having to fix obsolete CI setups, broken compilers, and so on (I helped him with 3/165 and it was already painful ahah). An obsolete library does not exist in a vacuum: it must coexist with the others, and someone pays for it, either in maintainer time or in user frustration over features that are slow to arrive (modular builds being the obvious example - several French people complained about it).
But as Rene and Vinnie mentioned, the first step is to remove internal use anyway, which should take a few years. And to begin somewhere, we should at least have some priority ranking of the libs Joaquin listed, be it for candidate maintainers matching or for planning internal use removal steps.
Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries.
Right now, the path "this lib is unmaintained" -> “i'm interested” -> “I'm maintainer” is hard (impossible?) to see from the outside. A clear handover process could help: a clickable button on the Boost website that filters unmaintained libs, who to contact, how ownership gets transferred, a trial period as co maintainer, and an onboarding document.
Best wishes, Arnaud Becheler _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/UQSQIMNC...
В письме от вторник, 20 октября 2026 г. 21:25:45 MSK пользователь Arnaud Becheler via Boost написал:
Unless a library is entirely non-functional, I don't see how removing it would help anyone.
I think different people are optimizing along different axes:
1. Maintenance allocation... 2. Discoverability... 3. Cross repository cost...
What if we created a project for legacy libraries? I mean specifically unmaintained libraries that don't have Boost users and shouldn't have new users. E.g. StaticAssert was moved to Config, but the project is still there. Foreach probably can be trivially replaced everywhere in Boost with for loops, since we effectively require C++11 for almost all libraries. So, let's create a Legacy library that will be the place of final rest with these obsolete libraries. That would significantly simplify required maintenance for them. It would be one build.jam, one CMakeLists.txt, one meta/libraries.json, include directory, possibly example and/or test directories, no or very bare bones CI (just check that headers are installed). Maintaining such project would pretty much involve only updating build scripts when something in the superproject changes or when another library becomes legacy. I personally can volunteer to do that. Of course, the simplicity of this arrangement relies on these libraries being header-only. E.g., it wouldn't be applicable to Coroutine.
On 20/10/2026 18:44, Matt Borland via Boost wrote:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap
Should we think about retiring and removing libraries for some of these? For example: foreach and tuple should have been replaced C++11 and scope replaces scope_exit. My first reaction was: sure, yes! Example tuple: users can just use std::tuple, if they have C++11+, or continue using the current version of boost tuple. The current version is like the previous version, is like the next version, when unmaintained.
But the thoughts and information highlighted by Arnaud, Peter and Peter, later in this thread, seem to show that this might be quite laborious in the end; the crux being the internal dependencies and minimal C++ version targeted by some (other) libraries. Continuing the tuple example: tuple is used by multi_index (P.D.) multi_index is classified active,maintained,unique (P.T.) multi_index aims for C++03 (P.T.) => multi_index can't switch to std::tuple . (Just the first example I found.) This is not to discourage the basic thought of retiring some libraries. I just wanted to explicitly connect some dots of this discussion, so this aspect can be integrated into the solution process early on. Cheers, Kai-- "Alliance, n. In international politics, the union of two thieves who have their hands so deeply inserted in each other's pockets that they cannot separately plunder a third." (Ambrose Bierce) -----BEGIN GEEK CODE BLOCK----- VERSION: 3.12 GCS/IT d- s: a++>-----(?) C++$ UL++(++++) P++ L++$ E-(+) W--(+) N !w--- !O !M V? PS+ PE-() Y+ PGP++ t R@* tv--(-) b+>++ DI++ G e+++(*) h? y? ------END GEEK CODE BLOCK------
El 20/10/2026 a las 22:17, Kai Bartels via Boost escribió:
On 20/10/2026 18:44, Matt Borland via Boost wrote:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap
Should we think about retiring and removing libraries for some of these? For example: foreach and tuple should have been replaced C++11 and scope replaces scope_exit. My first reaction was: sure, yes! Example tuple: users can just use std::tuple, if they have C++11+, or continue using the current version of boost tuple. The current version is like the previous version, is like the next version, when unmaintained.
But the thoughts and information highlighted by Arnaud, Peter and Peter, later in this thread, seem to show that this might be quite laborious in the end; the crux being the internal dependencies and minimal C++ version targeted by some (other) libraries. Continuing the tuple example: tuple is used by multi_index (P.D.) multi_index is classified active,maintained,unique (P.T.) multi_index aims for C++03 (P.T.) => multi_index can't switch to std::tuple . (Just the first example I found.)
Re MultiIndex, the library actually requires C++11 (https://github.com/boostorg/multi_index/blob/develop/meta/libraries.json). Starting with Boost 1.91, most user-facing tuples are std::tuples or either both boost::tuple and std::tuple are equally accepted (https://www.boost.org/doc/libs/latest/libs/multi_index/doc/release_notes.htm...). The remanining hard dependency on Boost.Tuple is in multi_index_container::ctor_args_list, but this could be eliminated without much effort should Boost.Tuple cease to exist. Joaquín M López Muñoz
On Tue, Oct 20, 2026 at 9:26 AM Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:
...
Let me suggest if there is interest for eventual removal, that it could progress in stages. 1. mark the to-be-removed libraries specially on the website 2. then separate those libraries visually (a second list below the primary one, a second grouping) 3. then separate them in the release package "include_legacy/boost" for example 4. then make them a separate release package 5. then stop putting out new releases of legacy libraries At each stage if there is too much pushback, or we get new information, then we can roll back or stand pat.
May I suggest: 0. Remove internal use of the to-be-removed libraries. After all, if boost can’t do without it, we can’t expect others to do so. Howard On Oct 20, 2026, at 12:55 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
1. mark the to-be-removed libraries specially on the website 2. then separate those libraries visually (a second list below the primary one, a second grouping) 3. then separate them in the release package "include_legacy/boost" for example 4. then make them a separate release package 5. then stop putting out new releases of legacy libraries
On Tue, Oct 20, 2026 at 12:35 PM Howard Hinnant via Boost < boost@lists.boost.org> wrote:
May I suggest:
0. Remove internal use of the to-be-removed libraries.
After all, if boost can’t do without it, we can’t expect others to do so.
I think that's the best we can do at the moment. Of course the issue is that doing that almost certainly is hard because such internal uses are likely libraries that also need maintenance help. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On 20 Oct 2026 19:25, Joaquin M López Muñoz via Boost wrote:
It is generally known within the community that some of the libraries in Boost are not being properly maintained: issues pile up without a prompt (or any) response from the nominal maintainers, eroding the libraries' usefulness and, ultimately, their viability. There are a number of stalwart contributors (Peter Dimov, Andrey Semashev, and others) who work to make sure CI tests stay green throughout the project, but beyond that they can't possibly address outstanding issues and evolution requests for all libraries.
Any initiative to try to remedy this situation begins with identifying its true extent. My colleagues at the FSC and I have gone through all Boost libraries and identified those that we regard as unmaintained, as evidenced by the presence of many important issues that go unresolved without anyone addressing them. This is the list:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap
I think, a big missing one is Boost.Thread. I'm not sure about the current status of the older versions of Boost.Spirit, as last time it was brought up only the newest version of Boost.Spirit was declared as maintained.
* Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries. For starters, unmaintained libraries could be labeled as such on the website to attract people potentially interested in taking over (and to warn potential users about long-term adoption risks).
Attracting more people to become maintainers is good, but I wouldn't want to mark these libraries as obsolete or deprecated. Some of these libraries I actively use and have no problems doing so. Detracting people from useful and working libraries would be a disservice to them and to Boost.
El 20/10/2026 a las 19:26, Andrey Semashev via Boost escribió:
On 20 Oct 2026 19:25, Joaquin M López Muñoz via Boost wrote:
It is generally known within the community that some of the libraries in Boost are not being properly maintained: issues pile up without a prompt (or any) response from the nominal maintainers, eroding the libraries' usefulness and, ultimately, their viability. There are a number of stalwart contributors (Peter Dimov, Andrey Semashev, and others) who work to make sure CI tests stay green throughout the project, but beyond that they can't possibly address outstanding issues and evolution requests for all libraries.
Any initiative to try to remedy this situation begins with identifying its true extent. My colleagues at the FSC and I have gone through all Boost libraries and identified those that we regard as unmaintained, as evidenced by the presence of many important issues that go unresolved without anyone addressing them. This is the list:
accumulators, align, callable_traits, circular_buffer, compute, concept_check, contract, convert, date_time, foreach, format, function_types, functional, fusion, hana, hof, integer, lambda, local_function, logic, multi_array, numeric_conversion, odeint, parameter, phoenix, polygon, pool, preprocessor, property_tree, proto, ptr_container, range, rational, scope_exit, statechart, stl_interfaces, tokenizer, tti, tuple, type_erasure, ublas, units, variant, vmd, xpressive, yap I think, a big missing one is Boost.Thread. Ok, we ticked Thread green because you seemed very active on it, but maybe you're only doing CI maintenance there. Adding it to the list. I'm not sure about the current status of the older versions of Boost.Spirit, as last time it was brought up only the newest version of Boost.Spirit was declared as maintained. Spirit had a split vote within the FSC and the most optimistic assessment was taken. Adding it to the list. * Please share any ideas on how to improve the situation so that we get more people actively maintaining more libraries. For starters, unmaintained libraries could be labeled as such on the website to attract people potentially interested in taking over (and to warn potential users about long-term adoption risks). Attracting more people to become maintainers is good, but I wouldn't want to mark these libraries as obsolete or deprecated. Some of these libraries I actively use and have no problems doing so. Detracting people from useful and working libraries would be a disservice to them and to Boost.
Noted. The maintenance and deprecation axes are relatively orthogonal, and even though I started this thread asking about the former, people naturally gravitate towards the latter. To be clear, when we've got this maintenance list settled on, we'll move to somehow showing the info on the website; what to do with deprecation remains an independent issue. Joaquín M López Muñoz
participants (13)
-
Amlal El Mahrouss -
Andrey Semashev -
Arnaud Becheler -
Dmitry Arkhipov -
Howard Hinnant -
Ivan Matek -
Joaquin M López Muñoz -
Kai Bartels -
Matt Borland -
Peter Dimov -
Peter Turcan -
René Ferdinand Rivera Morell -
Vinnie Falco