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