On 11/11/23 5:29 PM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
I can't see why one would ever want to do that.
Often because the feature has been developed at their request, and they don't want to wait for the next Boost release to take advantage of it.
They wouldn't have to wait until the next release. Any such feature would be merged into the master as soon as it was done/ready.
This also works in the other direction, for features being deprecated and removed - fixing the deprecation warnings should be done sooner than later,
As they would be under the new system.
because our users aren't particularly impressed if our own libraries emit warnings because they use deprecated features of other Boost libraries.
Right. Under the new system they would find out at the earliest possible time.
For the user, Boost is a whole,
That's an interesting perspective. I'm still attached to the "modular" boost idea where each library + it's dependencies stands (mostly) independent from the rest of boost. and it should keep its house in order.
which we're trying to do. Broadening the concerns and responsibilities of each library developer to include all of boost doesn't scale and makes library development a lot harder. This really is a disincentive to contribute to boost in the first place. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost