Zsh Mailing List Archive
Messages sorted by:
Re: Plan for the 5.9 branch
- X-seq: zsh-workers 45442
- From: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Plan for the 5.9 branch
- Date: Sun, 16 Feb 2020 14:52:29 +0000
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- List-unsubscribe: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <email@example.com>
On Sun, 2020-02-16 at 11:15 +0000, Daniel Shahaf wrote:
> A few weeks ago I created a 5.9 branch for bugfixes/patches that seemed
> too risky to push to master during pre-release stabilization.
> I'd like to merge that branch to master in a few weeks, when it's clear
> there won't be a 5.8.1 for regressions.
> (Alternatively, we could merge the branch now; that won't block us from
> creating a 5.8.1 regression-fixing release with or without the changes
> from the 5.9 branch.)
We can probably wait the odd week to see if there's any sorting
out, but there doesn't seem to be any point hanging on too long.
> As to branching policy, in the future we should probably do things the
> other way around; that is: in the run-up to the 5.9 release next year,
> rather than stabilize on master and open a 5.10 branch for destabilizing
> changes, we should open a 5.9 branch for stabilization and leave master
> open to destabilizing changes.
> (Fortunately, due to how git fast-forward merges work, the current 5.9
> branch won't interfere with this plan.)
That would be more standard.
The counter argument is that anyone tracking the shell is most likely to
stick with the master branch, so that's the one that gets the most
testing. However, as long as all changes are on the master branch we
should see any issues with the release anyway.
Messages sorted by: