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