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