From: dana <dana@dana.is>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Plan for the 5.9 branch
Date: Wed, 19 Feb 2020 14:00:46 -0600 [thread overview]
Message-ID: <1DC56D9E-1D16-43DA-AC7E-A2189398926B@dana.is> (raw)
In-Reply-To: <CAH+w=7bYXpzny-eLj2-p+HSZ+0W=fu4-QP3xdYh5wxhq4MMarw@mail.gmail.com>
On 18 Feb 2020, at 14:44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Each proposed change goes on its own branch created from master. This
> is rebased on master if necessary before merging with other changes.
We do this part where i work as well. The topic-branch thing seems to be most
beneficial when you're using those branches for QA, or when you're using
something like GitLab for reviews and/or MRs; in a system like this where we
just e-mail patches around anyway, i guess it doesn't make a huge difference
outside of each dev's personal work-flow
On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 1. Release 5.8.1 from master, including the several small changes that
> have already been pushed.
Which is what we've been doing, and it's fine, as long as master hasn't moved
on, or it's not preventing it from doing so. I'm definitely not concerned if a
few documentation/test/completion improvements make it into a .1
On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Let's try to reach a self-contained definition. How about the
> following blacklist rule: backported changes shouldn't be destabilizing
> or invasive and shouldn't introduce new APIs? Or a whitelist rule:
> changes should fix a bug or add a small/localized feature, while also
> meeting the aforementioned (blacklist) criteria?
Both of those seem unobjectionable to me
On 19 Feb 2020, at 04:32, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Now, suppose we add a new feature in March, then in April make
> a release off master that ships that feature, and then in May we find
> a bug in that feature. Are we allowed to break compatibility with the
> the April version of the feature in order to fix the bug?
Are the considerations in this scenario any different from how it is now?
Maybe i'm not following. Either way, in general, i agree with what Bart said
dana
next prev parent reply other threads:[~2020-02-19 20:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-16 11:15 Daniel Shahaf
2020-02-16 14:52 ` Peter Stephenson
2020-02-17 2:47 ` dana
2020-02-17 9:19 ` Daniel Shahaf
2020-02-18 19:40 ` dana
2020-02-18 20:44 ` Bart Schaefer
2020-02-19 10:23 ` Daniel Shahaf
2020-02-19 10:32 ` Daniel Shahaf
2020-02-19 15:21 ` Bart Schaefer
2020-02-19 20:00 ` dana [this message]
2020-03-07 22:07 ` Daniel Shahaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1DC56D9E-1D16-43DA-AC7E-A2189398926B@dana.is \
--to=dana@dana.is \
--cc=d.s@daniel.shahaf.name \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).