[release] Boost 1.75.0 Beta 1 Release Candidate 2

newer
[leaf] Request to merge bug fix to...

older
[release] Fixing Boost.Rational...

Marshall Clow

12 Nov 2020 12 Nov '20

7:02 a.m.

The second release candidates for the 1.75.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/ The SHA256 checksums are as follows: 3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

Show replies by date

Emil Dotchevski

12 Nov 12 Nov

7:37 a.m.

Successfully built rc2 on Mac for 03, 11, 17, 2a. On Wed, Nov 11, 2020 at 11:03 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

-- The Release managers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Richard Hodges

7:59 a.m.

initiating command: $ ./b2 toolset=clang variant=release cxxstd=11,14,17,20 --layout=versioned -j64 stage error: error: Name clash for '

libboost_atomic-clang11-mt-x64-1_75.so.1.75.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxstd>11 error: - <cxxstd>14 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. I think I've been told before that this is not actually an error because the cxxstd is not part of the ABI. However, it seems to me that this position will become untenable as C++ evolves. On Thu, 12 Nov 2020 at 08:03, Marshall Clow via Boost wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

-- The Release managers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Richard Hodges

8:25 a.m.

Clang11, Fedora 33: with: $ ./b2 toolset=clang variant=release cxxstd=20 --layout=versioned -j64 stage Many warnings like this: clang-linux.compile.c++.without-pch bin.v2/libs/locale/build/clang-linux-11.0.0/release/cxxstd-20-iso/link-static/threadapi-pthread/threading-multi/visibility-hidden/std/std_backend.o In file included from libs/locale/src/std/std_backend.cpp:9: ./boost/locale/localization_backend.hpp:109:18: warning: 'auto_ptrboost::locale::localization_backend' is deprecated [-Wdeprecated-declarations] std::auto_ptr get() const; ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward/auto_ptr.h:287:7: note: 'auto_ptrboost::locale::localization_backend' has been explicitly marked deprecated here } _GLIBCXX_DEPRECATED; ^ On Thu, 12 Nov 2020 at 08:03, Marshall Clow via Boost wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

-- The Release managers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Andrey Semashev

12:14 p.m.

On 11/12/20 11:25 AM, Richard Hodges via Boost wrote:

...

Clang11, Fedora 33:

with:

$ ./b2 toolset=clang variant=release cxxstd=20 --layout=versioned -j64 stage

Many warnings like this:

clang-linux.compile.c++.without-pch bin.v2/libs/locale/build/clang-linux-11.0.0/release/cxxstd-20-iso/link-static/threadapi-pthread/threading-multi/visibility-hidden/std/std_backend.o In file included from libs/locale/src/std/std_backend.cpp:9: ./boost/locale/localization_backend.hpp:109:18: warning: 'auto_ptrboost::locale::localization_backend' is deprecated [-Wdeprecated-declarations] std::auto_ptr get() const; ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward/auto_ptr.h:287:7: note: 'auto_ptrboost::locale::localization_backend' has been explicitly marked deprecated here } _GLIBCXX_DEPRECATED; ^

https://github.com/boostorg/locale/issues/27 This had also come up on this list, I think. PS: Please, don't top post.

Richard Hodges

8:35 a.m.

With: ./b2 toolset=clang stdlib=libc++ variant=release cxxstd=20 -j64 stage warnings in locale: clang-linux.compile.c++.without-pch bin.v2/libs/locale/build/clang-linux-11.0.0/release/cxxstd-20-iso/link-static/stdlib-libc++/threadapi-pthread/threading-multi/visibility-hidden/icu/formatter.o libs/locale/src/icu/formatter.cpp:210:27: warning: implicit conversion from 'std::__1::numeric_limits<long>::type' (aka 'long') to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-const-int-float-conversion] if(date > limits_type::max() || date < limits_type::min()) ~ ^~~~~~~~~~~~~~~~~~ On Thu, 12 Nov 2020 at 08:03, Marshall Clow via Boost wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

-- The Release managers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

Tom Kent

1:03 p.m.

Windows/Visual Studio builds look good. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build results can be found here: https://gist.github.com/teeks99/24ba113c7cada3da8959d02fd1d67079 Tom On Thu, Nov 12, 2020 at 1:02 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

-- The Release managers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Marshall Clow

2:25 p.m.

On Nov 11, 2020, at 11:02 PM, Marshall Clow wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

<https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/ https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/>

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

I have successfully built the libraries on Mac OS 10.15.7 with Apple clang version 11.0.3 (clang-1103.0.32.62) with the following configurations: * cxxstd=03 * cxxstd=11 * cxxstd=14 * cxxstd=17 * cxxstd=2a — Marshall

Marshall Clow

2:26 p.m.

On Nov 11, 2020, at 11:02 PM, Marshall Clow wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

<https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/ https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/>

The SHA256 checksums are as follows:

3f01d3e5dc822e151892040d4667e364ea808d208d2e49cc7a1802bd4da3d4cc boost_1_75_0_b1_rc2.7z 9b75a80f845d4ae312e3c9151ffdfe3fed450973095e0a15c68d0be394f2f2df boost_1_75_0_b1_rc2.tar.bz2 123519d4b056fbbd69e452db880abe2c7e55f21779d44a4d6b6c714d5c13c3ee boost_1_75_0_b1_rc2.tar.gz b73e01d22d5b3d2ff82f14a371e3974fab30448bf6ff5ac8b9c829539a19c2d7 boost_1_75_0_b1_rc2.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

I have successfully built the libraries on Ubuntu 18.04 With gcc 7.0.5 with the following configurations: * cxxstd=03 * cxxstd=11 * cxxstd=14 * cxxstd=17 And with Apple clang tip-of-tree with the following configurations: * cxxstd=03 * cxxstd=11 * cxxstd=14 * cxxstd=17 * cxxstd=2a — Marshall

Marshall Clow

3:30 p.m.

On Nov 11, 2020, at 11:02 PM, Marshall Clow wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

<https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/ https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/>

I should have mentioned this last night. The changes from RC1 are: * Fixes to Boost.Fiber to fix compilation problems on recent MSVC releases. — Marshall

Robert Ramey

4:30 p.m.

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

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

When will be permitted to merge develop into release. I thought there would be an opportunity between RC1 and RC2. I need to do this for both libraries I maintain: safe_numerics and serialization Robert Ramey

Andrey Semashev

4:50 p.m.

On 11/12/20 7:30 PM, Robert Ramey via Boost wrote:

...

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

...
The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

When will be permitted to merge develop into release. I thought there would be an opportunity between RC1 and RC2.

The master branch will be open after the beta is released. The release candidates were for the beta, so it has not yet been released. Yes, RC of a beta is confusing and I wish we just used a single nomenclature for pre-releases - either betas or RCs.

Marshall Clow

5 p.m.

On Nov 12, 2020, at 8:50 AM, Andrey Semashev via Boost wrote:

...

On 11/12/20 7:30 PM, Robert Ramey via Boost wrote:

...
On 11/11/20 11:02 PM, Marshall Clow via Boost wrote:

...
The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

When will be permitted to merge develop into release. I thought there would be an opportunity between RC1 and RC2.

The master branch will be open after the beta is released. The release candidates were for the beta, so it has not yet been released.

Yes, RC of a beta is confusing and I wish we just used a single nomenclature for pre-releases - either betas or RCs.

The beta releases cause activity outside the boost community. We want to minimize the number of beta releases (ideally, one per boost release). Hence the trial runs (aka ‘RC’s) — Marshall

Andrey Semashev

5:08 p.m.

On 11/12/20 8:00 PM, Marshall Clow wrote:

...

On Nov 12, 2020, at 8:50 AM, Andrey Semashev via Boost wrote:

...
On 11/12/20 7:30 PM, Robert Ramey via Boost wrote:

...
On 11/11/20 11:02 PM, Marshall Clow via Boost wrote:

...
The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

When will be permitted to merge develop into release. I thought there would be an opportunity between RC1 and RC2.

The master branch will be open after the beta is released. The release candidates were for the beta, so it has not yet been released.

Yes, RC of a beta is confusing and I wish we just used a single nomenclature for pre-releases - either betas or RCs.

The beta releases cause activity outside the boost community. We want to minimize the number of beta releases (ideally, one per boost release).

Why try minimizing it? And why it is Boost to decide which pre-releases to consume downstream?

Emil Dotchevski

5:16 p.m.

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? Clearly, under the Boost license, people can consume whatever they like.

Andrey Semashev

7:53 p.m.

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

Marshall Clow

8:57 p.m.

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.

...

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. — Marshall

Andrey Semashev

9:38 p.m.

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.

Peter Dimov

10:21 p.m.

Andrey Semashev wrote:

...

I meant that the policy appears to be chosen to influence the downstream consumers.

No, the policy has been chosen in response to what downstream customers do.

Alexander Grund

16 Nov 16 Nov

7:46 a.m.

...

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

Marshall Clow

2:07 p.m.

On Nov 15, 2020, at 11:46 PM, Alexander Grund via Boost wrote:

...

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

It wasn’t. Not until the beta was complete. — Marshall

Glen Fernandes

13 Nov 13 Nov

2:15 a.m.

On Thu, Nov 12, 2020 at 2:02 AM Marshall Clow wrote:

...

The second release candidates for the 1.75.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.75.0.beta1/source/

Successfully built with GCC 10.2.1 on Linux x86_64 5.8.18-300 (Fedora 33) with c++03, 11, 14, 17, 20. Glen

Richard Hodges

17 Nov 17 Nov

5:03 p.m.

I have a commit I'd like to merge to master when permitted. It's the Release Notes for Boost.Beast https://github.com/boostorg/beast/pull/2122/commits/bcca9959f5fbe9e4fc7151f8... There are no code changes in this commit.

Glen Fernandes

5:06 p.m.

On Tuesday, November 17, 2020, Richard Hodges via Boost wrote:

...

I have a commit I'd like to merge to master when permitted.

It's the Release Notes for Boost.Beast

https://github.com/boostorg/beast/pull/2122/commits/ bcca9959f5fbe9e4fc7151f8c4ae314fec5d1327

There are no code changes in this commit.

No permission required for this. Glen

1454

Age (days ago)

1459

Last active (days ago)

List overview

Download

23 comments

9 participants

participants (9)

Alexander Grund
Andrey Semashev
Emil Dotchevski
Glen Fernandes
Marshall Clow
Peter Dimov
Richard Hodges
Robert Ramey
Tom Kent