Re: Plan for the 5.9 branch

[Bart Schaefer <schaefer@brasslantern.com>]

On Tue, Feb 18, 2020 at 11:41 AM dana <dana@dana.is> wrote:
>
> Right. All i'm really worried about personally are fixes for security issues
> and the type of regressions we normally correct in .1 releases.

At my $WORK we use the following approach, parts of which might be
overkill for zsh-workers, but presented in case worth discussing:

The current release is always a version number tag on the master
branch, there are not branches for numbered releases.

Each proposed change goes on its own branch created from master.  This
is rebased on master if necessary before merging with other changes.
(In the zsh world this would probably mean creating a branch named for
a zsh-workers sequence number.)  Critical changes (post-release
regression fixes, security issues, etc.) can go directly from these
branches onto master for immediate release if necessary, at which time
a new version tag is created on master.

There's a development branch onto which anyone can merge/push pretty
much anything, even if it's not on a proposed branch yet, to test
conflicts/interactions, get feedback, etc.  This is sort of what we do
in zsh via vetting of patches on the mailing list.

Right before a release, a staging branch is created, which is the
master branch merged with whatever subset of the proposed change
branches are ready.  This is like the zsh*-test-N versions we've been
publishing, it's used to QA the assembled changes before they go on
the master branch, but it allows us to pick and choose which proposed
changes actually go into a release if some are "more thoroughly
cooked" than others.  Changes that result from QA get revision tags on
the staging branch.

For release, the staging branch is merged back onto master and a new
version tag is assigned to master.  Then the staging branch is
deleted, and not re-created until the next pre-release cycle.  The
development branch is usually sync'd up with the master branch at this
point as well, although what that means is mainly that there's nothing
on master that is missing from development.  Unless there's some large
unfinished project under way, it typically means the development
branch is made the same as the current master, because anything else
can be restored from the proposed change branches.