Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-11-12 21:38:20

On 11/12/20 11:57 PM, Marshall Clow via Boost wrote:
> On Nov 12, 2020, at 11:53 AM, Andrey Semashev via Boost <boost_at_[hidden]> wrote:
>> On 11/12/20 8:16 PM, Emil Dotchevski via Boost wrote:
>>> On Thu, Nov 12, 2020 at 9:08 AM Andrey Semashev via Boost <
>>> boost_at_[hidden]> wrote:
>>>> And why it is Boost to decide which pre-releases
>>>> to consume downstream?
>>> Are you asking why is it up to Boost to decide how we label each build?
>> No, I'm asking why is Boost trying to define its internal policies (pre-release naming scheme) so that downstream consumers are encouraged to use some pre-releases and discouraged to use others.
> You are using the wrong tense here.
> Boost is not "trying to define”…
> Boost HAS defined …
> You’re presupposing that this RCx for the beta releases is something new.
> 10 seconds of searching on my part found an email titled: "[boost] [1.40.0] Beta 1 release candidate available” dated August 10, 2009.

That was probably poor wording on my part, sorry. I was not implying
that this was a new policy. I have seen multiple Boost releases in the
past, and they followed the same procedure as this one. I meant that the
policy appears to be chosen to influence the downstream consumers.

>> To my mind, it is the downstream consumers' decision as to which releases to use or not. The only reasonable requirement on Boost should be to have stable official releases. Whether we have pre-releases, how many of them and how they are named is our convenience and a means to achieve the final stable release goal.
>> And if downstream consumers are interested in pre-releasses, I don't see why we should restrict them from using as many of the pre-releases as we make. This would only provide more testing and ultimately improve the quality of the final release.
> 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.

PS: And I'd like to take this chance to thank the review management team
for doing this work. Please, don't take my posts as a complaint.

Boost list run by bdawes at, gregod at, cpdaniel at, john at