From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id b3b879fd for ; Wed, 19 Feb 2020 20:01:29 +0000 (UTC) Received: (qmail 23963 invoked by alias); 19 Feb 2020 20:01:24 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45478 Received: (qmail 947 invoked by uid 1010); 19 Feb 2020 20:01:24 -0000 X-Qmail-Scanner-Diagnostics: from mail-yw1-f44.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25725. spamassassin: 3.4.2. Clear:RC:0(209.85.161.44):SA:0(-1.9/5.0):. Processed in 1.088311 secs); 19 Feb 2020 20:01:24 -0000 X-Envelope-From: dana@dana.is X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.161.44 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uXUAvZiIa0T33s0waWl0lhltcdh1smxDZtn0q4ghCHk=; b=WhuxksjrC8q6CP7ikbtfEg0GFvNN4oSfxj4WBTTivsEzG6iDpHoIFCvm5O3S2FkyFj gyNaYQ10ctPk/aG0CT44+PDxsNKUDKF5IvZJRCzc0ETVa6vX8eDFZCcqhSKPTXFXI6fU AwpwAagLblyZ+w5c0ijoDDh2nPnrApZnty33zcmoQkBdDs7iloyHQp7efergO61wNPrp 7I729+S4E2xUrmCS+p5L8acrRHDKefLfs8fYAhPSStJlZBDvbF+reVHBhSIzBX71/lNy Q5CO6GEMy7aWlzroAwBIEK3JMNjY67q/BHkoyuaxIYcBG6GjxpKN8efyYXm8wiopLfaU ol9g== X-Gm-Message-State: APjAAAVxlY0pZopxUBEqR563GN9G+gE/hURstU3mhM9KwAusxTMwASzG U+/96pTFimlTLotabkDUI56JOg== X-Google-Smtp-Source: APXvYqyua/qj5Tkp+UehCBOQ37FjYBv57DjnhMgbsjtLHwUAqtdsOiyyFIxiBbZh/lxMYiRxOE5FeQ== X-Received: by 2002:a0d:d448:: with SMTP id w69mr21348560ywd.271.1582142448587; Wed, 19 Feb 2020 12:00:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Plan for the 5.9 branch From: dana In-Reply-To: Date: Wed, 19 Feb 2020 14:00:46 -0600 Cc: Daniel Shahaf , Zsh hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <1DC56D9E-1D16-43DA-AC7E-A2189398926B@dana.is> References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> <20200217091958.0fa9f1d8@tarpaulin.shahaf.local2> <20200219103205.0aa6f13f@tarpaulin> To: Bart Schaefer X-Mailer: Apple Mail (2.3445.104.11) On 18 Feb 2020, at 14:44, Bart Schaefer = 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 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 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 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