On 26-08-17 13:30, Daniel James via Boost wrote:

git checkout boost-1.65.0 -b fixes/1.65 git cherry-pick (commit-hash)

Going the cherry-pick route is asking for trouble IME. By cherry-picking instead of basing of an existing (permanent) reference/commit you run the risk of introducing regressions when the next release uses the same change, but from different commit. It also becomes hard to have clear release notes (the release notes for the point release are essentially separate from either the base or the next release. This is not what end-users expect.) Just my $0.02. Then again, this model might be PERFECT for true hot-fixes. Just be sure to communicate what a point release is, and what it is used for. Make syre maintainers AND end-users are aware of the purpose. Seth

Daniel James wrote:

We could use a more complicated branching scheme to merge the changes back into the main branches.

My old suggestion was (still is) that we could use a dedicated 'release' superproject branch for the releases, avoiding the need to freeze master. When starting a release, the release manager would `git merge master` into `release`, then potentially cherry-pick "update foo" master commits as needed (the bot would need to be changed to not compress more than one change into a single commit.) The same `release` branch would then be used for the point release in the same manner - cherry-pick commits to superproject `master`. When I first suggested it, the problem point was that the testers would have to test `release` as well which would either waste time (as it would seldom change) or require a smarter infrastructure that doesn't re-test the branch unless it changes. But we don't rely that much on the testers nowadays, so this would be less of an issue.

On 08/26/17 14:30, Daniel James via Boost wrote:

On 26 August 2017 at 12:18, Andrey Semashev via Boost wrote:

...

I don't mind a point release, but I have to confess I've started merging my changes from develop to master already. If the point release is going to be based on the current master, I will have to either back out these changes or update the release notes which currently refer to 1.66. Please, let us know what git state will be used for the point release.

I'll be updating the super project manually, so they can be taken from a branch. Perhaps using something like:

git checkout boost-1.65.0 -b fixes/1.65 git cherry-pick (commit-hash)

You mean fixes/1.65 will be a branch in the sub-projects? IIUC, that means sub-projects' master need not be updated for 1.65.1. Thanks.

2017-08-26 19:21 GMT+02:00 Daniel James via Boost :

On 26 August 2017 at 16:39, Oliver Kowalke via Boost wrote:

...

+1, if 1.65.1 gets boost_1_65_0.patch merged

If I wasn't clear, boost_1_65_0.patch is basically what I'm proposing for 1.65.1. I want to be very stingy about changes.

unfortunately boost_1_65_0.patch needs to include commit https://github.com/boostorg/fiber/commit/440c7f799ae2e5a7718e5126d5b982bbd65... too

On 26 August 2017 at 17:54, Peter Dimov via Boost wrote:

VS 2017 update 3 got released during the RC phase, and it bumps the compiler version from 19.10 to 19.11, causing a Config warning about an unrecognized version, and also makes /std:c++17 default, which removes auto_ptr/unary_function/binary_function and consequently introduces errors.

1.65.1 might be a good opportunity to address some of these.

Sure, sounds like something that's reasonable, if someone creates the appropriate patches?

See numeric conversion https://github.com/boostorg/numeric_conversion/commit/7436ca711357d4d9a95201... There are also some python issues with autoptr detection but those (I think) are done but I am waiting for review. On Sat, Aug 26, 2017 at 11:39 AM, Peter Dimov via Boost wrote:

Daniel James wrote:

...

On 26 August 2017 at 17:54, Peter Dimov via Boost wrote:

...

VS 2017 update 3 got released during the RC phase, and it bumps the > compiler version from 19.10 to 19.11, causing a Config warning about an > unrecognized version, and also makes /std:c++17 default, which removes > auto_ptr/unary_function/binary_function and consequently introduces > errors.

1.65.1 might be a good opportunity to address some of these.

Sure, sounds like something that's reasonable, if someone creates the appropriate patches?

Might be a problem because Config master seems to have acquired a number of changes meanwhile, including a version bump to 1.66. :-)

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

Oh, it fixes hard compile errors on 17.3 in numeric_conversion which also gets dragged in by other stuff. On Sat, Aug 26, 2017 at 12:18 PM, Daniel James via Boost wrote:

On 26 August 2017 at 18:46, Gary Furnish via Boost wrote:

...

See numeric conversion https://github.com/boostorg/numeric_conversion/commit/7436ca711357d4d9a95201...

Did you intend to link to that commit? There's not much info in there.

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