Re: [release] Boost 1.75.0 Beta 1 Release Candidate 2

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-11-16 07:46:24

>> 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