Niall Douglas wrote:
It's funny how Boost.ASIO has suddenly gone from being a very, very conservative flavour of standalone ASIO, typically trailing by a few major versions, to where "the stable branch" is code literally written new in the last few weeks, and with a major rearchitecture to boot.
In the end, each library maintainer gets to make that call for their own library.
In principle we have a three-tiered procedure of rolling out API changes: 1. Update develop This gets feedback from other Boost library developers who depend on the API and test against the develop branch. 2. Update master This is supposed to get feedback from outside users who track master in order to not be surprised by the release, but in practice, no such people seem to exist, so it mostly gets feedback from Boost library developers who erroneously test against master. 3. Get a release out This gets feedback from everyone else. Theoretically, (1) should happen at some point during release cycle N-1, (2) happens in the beginning of release cycle N, and (3) happens at the end of release cycle N. In practice though, not much is gained by spreading them out. Most of the world doesn't care unless changes go out in a release. I'd still call the above schedule "best practice" though; or if not that, its compressed form where (1) is at beginning of N, (2) is in the middle.