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

On 11/12/20 11:57 PM, Marshall Clow via Boost wrote:

On Nov 12, 2020, at 11:53 AM, Andrey Semashev via Boost 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@lists.boost.org> 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.