Boost logo

Boost :

Subject: Re: [boost] [1.65.0] Point release?
From: Daniel James (dnljms_at_[hidden])
Date: 2017-08-26 12:22:25

On 26 August 2017 at 12:40, Seth via Boost <boost_at_[hidden]> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at