may boost should look at the way the build tree is managed, on a way something like that (using 'asio' as a examble, but could be 'spirit' and all others) ... ex: boost_root git tree src edge spirit (submodule from 'boost_spirit' repo, point to 'develop' branch or something like that) asio (submodule from 'boost_asio' repo, point to 'develop' branch or something like that) stable spirit (submodule from 'boost_spirit' repo, point to latest 'stable' (and compatible with boost) branch or something like that) asio (submodule from 'boost_asio' repo, point to latest 'stable' (and compatible with boost) branch or something like that) then authors (and/or boost release mantainers?) update 'stable' branch references with latest stable and tested libraries for release... the boost build process could create more targets with something like 'source=stable' (as default) and have a option 'source=edge' (or some other name). also could be by 'library', as 'source=stable specific_source=spirit/edge'... (to help testing with specific edge libraries) i don't know if this may not be a good way of handling this situation, but serves as inspiration for creating something to take care of boost development and releases, and author doing all the work on external libraries the way they want, while trying to keeping some things stabilized On Fri, Sep 12, 2025 at 12:12 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Thu, Sep 11, 2025 at 6:05 PM Joel de Guzman via Boost < boost@lists.boost.org> wrote:
That being said, I urge the Boost community to maintain a kind and welcoming tone. That was not the case in the message that started this thread. Maintaining a library is NOT a trivial task, everyone knows that, and it is disheartening to see maintainers leave because of the toxicity. Here's one from @Kolejey from May 8:
"The main reason I've stopped working on improvements is because I got yelled pretty much every time I fix a bug or change some internal stuff that no one should've relied on. And I get their viewpoint, Boost nowadays is seen as a collection of mostly legacy battle- tested libraries, a project uses Boost because it have used it for a long while and people that maintain it don't want their working code been disturbed."
And this reflects the scenario we have now, again.
Indeed.
As a community, we failed here. And I'm including myself in this as well.
We were so quick to get riled up and argue and bicker with each other, that we missed the obvious solutions and steps.
We should've simply shown the new maintainer how to use boostdep, how to do regression testing across the list of reported libraries and then instructed them on how we roll out large deprecating changes, similar to the C++03 deprecation.
We could've avoided a lot of pain and drama.
Alas, the cost of wisdom is foolishness and at the very least, I know what to do in the future now, should this situation ever arise again.
The only thing we can do here is learn and do better in the future.
- Christian _______________________________________________ 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/4Q7HA4TK...