On Nov 13, 2025, at 8:07 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:

On 13 Nov 2025 18:50, Marshall Clow via Boost wrote:

...

Hi,

The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in:

https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy

The next deadline: On December 3rd, master closes for all changes.

As always, the calendar is at https://www.boost.org/calendar

I would like to merge the following fix to Boost.Filesystem master:

https://github.com/boostorg/filesystem/compare/master...develop

This is a workaround for an "Invalid Signature" error on Windows, when a directory iterator is used to access a Samba 3.0.2 share.

And also a fix in Boost.Log:

https://github.com/boostorg/log/compare/master...develop

This fixes a very long loop and pointless in text_file_backend, when it tries to rotate a log file while there is no file counter placeholder in the file name pattern.

There are also two commits with CI cleanup.

Go ahead. — Marshall

On Nov 14, 2025, at 12:16 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

The diff alone may give the impression that this is a high risk change, but it essentially restores the 1.89 behavior on Clang, so it shouldn't be.

That was certainly my first impression. If you’re happy with the test results, go ahead. — Marshall

On Nov 16, 2025, at 9:45 AM, Jean-Louis Leroy via Boost <boost@lists.boost.org> wrote:

Greetings Marshall,

Newcomer here :)

Welcome!

I'd like to merge the following changes to master.

* https://github.com/boostorg/openmethod/commit/52fa71306e1cc41920d2b099446dcf...

This works around a shortcoming in the Antora-MrDocs toolchain. MrDocs generates a link to the header where a name is defined. The URL is calculated using the base-url attribute in mrdocs.yml. Its value must reflect the commit from which the doc was built.

Just a note here - you don’t need permission to merge doc changes.

* https://github.com/boostorg/openmethod/commit/dac3cf7087e70e8090768bfcf87fd2...

This tells codecov to ignore a function that exists only to force the instantiation of a method in a test suite for examples featured in the doc.

This looks fine to me.

* https://github.com/boostorg/openmethod/commit/4d91aab7fd7375b9458e3ae63c5f34...

This makes 'finalize' symmetric with 'initialize'. The change is backward compatible with master (and OpenMethod is a new library anyway).

New library - no installed base to break - ;-) Go ahead.

* https://github.com/boostorg/openmethod/commit/b8da0a108892362a1a6f0b3bc4c2b7...

This removes 'initialize' from namespace 'boost::openmethod::aliases', which is a namespace that makes it easy to import a few names that are used very frequently. 'initialize' is not one of them, as it is typically called only in 'main'. Again, there is no previous version of the library to be compatible with.

Go ahead. But keep an eye on the test results. — Marshall

On Nov 21, 2025, at 10:06 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

...

Marshall Clow wrote:

...

Hi,

The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in:

https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy

I'd like to merge the following changes to Compat:

https://github.com/boostorg/compat/compare/master...develop

This undoes the addition of the public header boost/compat/nontype.hpp for this release. We'll add constant_arg.hpp (or whatever) later.

Some more context about this:

In 1.89, boost::compat::nontype_t was defined in boost/compat/function_ref.hpp, because it's part of its public API (some function_ref constructors take nontype_t<f>.) It was left largely undocumented.

In 1.90 beta, I had moved it to a public header, boost/compat/nontype.hpp, with proper documentation. However, the committee changed its mind at the Kona meeting, which happened after our beta, and decided that nontype_t would be better named constant_arg_t.

I'm not 100% sure that this is the final name of the component; it seems so, but there are opinions that another new standard component, std::cw, the new replacement of std::integral_constant, ought to be used instead in std::function_ref's interface. Plus, doing substantial changes to a public API, be it a new one, between beta and release doesn't sound good.

So, instead, what I propose to do, and the commits above implement, is that the new public header is "unpublished" for 1.90 - moved to detail/ and removed from the documentation. From the outside, this leaves us exactly where we were in 1.89 - nontype_t is still defined by function_ref.hpp, and is still underdocumented.

Once 1.90 ships, I'll rename the header to constant_arg.hpp and re-publish it.

I’m fine with that. — Marshall