They’re all welcome to test any/all of our builds - including the daily develop snapshots. When we release a beta version (and announce it to the world), we’re attempting to promise some modicum of quality.
Trial runs (aka RCs) help ensure that.
Fair enough. I'm just not sure how useful that is - to users and to Boost.
From users perspective, a beta is a beta, however you call it. And many, if not all projects I'm familiar with that release betas, seem to consider them the same way - as steps of preparation before the final release, with gradually increasing quality. I mean, if you want a stable release, you probably won't install a beta 1 of a Linux kernel. You might even hesitate to install a .0 final release for good measure. Depending on how adventurous you feel, you might install more early betas for a spin.
For Boost, the current procedure seem to cause much confusion for maintainers regarding when they may or may not merge to master and what has and has not been released. I'm not sure if it has any pressure on release managers, but I suspect it does, because they have to review merge requests and release RCs in an expedited way. FWIW: It makes sense to have it this way. The RCs are a way for Boost to internally test changes so the target audience is mainly Boost developers. Master branches are frozen, only approved bugfixes are allowed inbetween RCs. So no regressions should be introduced at this point.
The beta then has a larger audience where package maintainers etc. can test, if everything still compiles in their environments which is often different from Boosts and the test runners. Ideally nothing but trivial bugfixes should be added at this point. And if nothing comes up the beta state can be label final (which is what others do with RCs) BTW: I'm a bit confused why the safe_numerics and serialization "develop to master sync" is allowed at this point. It doesn't fit my understanding of the release process but maybe the changes are small enough. Changing that now may break the scripts package maintainers etc have set up and causes them to employ hacks to deal with the pre- and post-this-change situation. Alex