[1.65.0] Point release?
Hello all, What do you think about having a point release? I tried asking the other release managers but didn't get any reply. Some are away, and I don't known when they will be available again. I think we have to decide soon, as it's holding up development. This would deal with the issues in thread, context, fiber, and possibly others. I've added patches to the release notes: http://www.boost.org/users/history/version_1_65_0.html A point release should take a week or two, perhaps more if we include other changes. thanks, Daniel
On 08/26/17 14:11, Daniel James via Boost wrote:
Hello all,
What do you think about having a point release? I tried asking the other release managers but didn't get any reply. Some are away, and I don't known when they will be available again. I think we have to decide soon, as it's holding up development.
This would deal with the issues in thread, context, fiber, and possibly others. I've added patches to the release notes:
http://www.boost.org/users/history/version_1_65_0.html
A point release should take a week or two, perhaps more if we include other changes.
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.
On 26 August 2017 at 12:18, Andrey Semashev via Boost <boost@lists.boost.org> 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)
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
On 26 August 2017 at 12:40, Seth via Boost <boost@lists.boost.org> wrote:
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.
I'd rather not include unnecessary changes. The changes should be cherry-picked from develop, so as long as they're also merged into master, they should be included in the next release. We could use a more complicated branching scheme to merge the changes back into the main branches. When we first used git, I tried using 'git flow' which does something like that, but I found it over-complicated and it made a complete mess of the version history. It's a lot simpler if a project doesn't have distinct master and develop branches (i.e. they usually use a fast forward merge from develop into master). I suppose we could create a branch from 'git merge-base boost-1.65.0 develop'. And then hopefully cleanly merge that into develop, master, and the fixes branch. If we're lucky, the changes will immediately follow that 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.)
I don't think it's unusual for a project to use a stable branch for releases, which the next version is developed on another branch. As long as we don't have too many changes, it shouldn't be hard to manage.
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 26 August 2017 at 18:02, Peter Dimov via Boost <boost@lists.boost.org> wrote:
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.
I was talking about the submodule branches. Branching the super project wouldn't gain much nowadays, as little is done directly in it.
But we don't rely that much on the testers nowadays, so this would be less of an issue.
I do. The turnaround on Travis is pretty terrible at the moment, and that's going to get worse as more modules use it.
On 08/26/17 14:30, Daniel James via Boost wrote:
On 26 August 2017 at 12:18, Andrey Semashev via Boost <boost@lists.boost.org> 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 13:11 GMT+02:00 Daniel James via Boost <boost@lists.boost.org>:
Hello all,
What do you think about having a point release? I tried asking the other release managers but didn't get any reply. Some are away, and I don't known when they will be available again. I think we have to decide soon, as it's holding up development.
This would deal with the issues in thread, context, fiber, and possibly others. I've added patches to the release notes:
http://www.boost.org/users/history/version_1_65_0.html
A point release should take a week or two, perhaps more if we include other changes.
+1, if 1.65.1 gets boost_1_65_0.patch merged
2017-08-26 19:21 GMT+02:00 Daniel James via Boost <boost@lists.boost.org>:
On 26 August 2017 at 16:39, Oliver Kowalke via Boost <boost@lists.boost.org> 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
Daniel James wrote:
Hello all,
What do you think about having a point release?
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.
On 26 August 2017 at 17:54, Peter Dimov via Boost <boost@lists.boost.org> 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?
Daniel James wrote:
On 26 August 2017 at 17:54, Peter Dimov via Boost <boost@lists.boost.org> 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. :-)
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 <boost@lists.boost.org> wrote:
Daniel James wrote:
On 26 August 2017 at 17:54, Peter Dimov via Boost <boost@lists.boost.org> 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
On 26 August 2017 at 18:46, Gary Furnish via Boost <boost@lists.boost.org> 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.
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 <boost@lists.boost.org> wrote:
On 26 August 2017 at 18:46, Gary Furnish via Boost <boost@lists.boost.org> 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
On 26 August 2017 at 20:39, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Might be a problem because Config master seems to have acquired a number of changes meanwhile, including a version bump to 1.66. :-)
Boost 1.66 (as opposed to 1.65.1), could also be a fast-track bug-fix-only-release, but then including all the out-standing issues. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
participants (7)
-
Andrey Semashev -
Daniel James -
degski -
Gary Furnish -
Oliver Kowalke -
Peter Dimov -
Seth