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 b6f98408 for ; Mon, 17 Feb 2020 09:20:42 +0000 (UTC) Received: (qmail 14371 invoked by alias); 17 Feb 2020 09:20:37 -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: 45446 Received: (qmail 24146 invoked by uid 1010); 17 Feb 2020 09:20:37 -0000 X-Qmail-Scanner-Diagnostics: from wout2-smtp.messagingengine.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(64.147.123.25):SA:0(-2.6/5.0):. Processed in 1.32517 secs); 17 Feb 2020 09:20:37 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeeigddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfgjfhfogggtgfesthhqtd dtredtjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgv lhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudejkedrjedrudekleenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Date: Mon, 17 Feb 2020 09:19:58 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: Plan for the 5.9 branch Message-ID: <20200217091958.0fa9f1d8@tarpaulin.shahaf.local2> In-Reply-To: <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable dana wrote on Sun, 16 Feb 2020 20:47 -0600: > On 16 Feb 2020, at 05:15, Daniel Shahaf wrote: > > 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. =20 >=20 > I like this. When we reach 'feature freeze' for 5.9, we branch off, only > back-port important stuff from master, and then release 5.9 based on that > branch. If we find any regressions or security bugs, we can back-port tho= se > fixes and release 5.9.1 or whatever. Yes. (When physically doing the commits to the two branches, I'm not sure if it'= ll be easier to cherry-pick, or to commit to the 5.9 branch first and then to run =C2=ABgit merge 5.9=C2=BB in master.) > Oliver pointed out before that nothing stops us from back-porting stuff a= nd > releasing patch versions now, Indeed, there's nothing stopping us from creating a 5.8 branch right now, if people are willing to maintain it. > but i think the important thing is to have a > standardised process for it. It makes the releases go smoothly, and it he= lps > everyone make sense of the repo and the version history. And obv we'd doc= ument > the process somewhere for anyone who might get confused. I think even before documenting the process, we'll have to agree on what the goal is and what the additional releases would contain. Just bugf= ixes, or also new features? What degree of support/compatibility promises will t= hey come with =E2=80=94 comparable to a -dev/-test release or to a regular rele= ase? Etc. > The main concern i've heard about it in the past is that maybe some of the > devs don't have the bandwidth for the extra work, but ideally the back-po= rts > would be infrequent, and presumably it'd fall on the RM to make sure noth= ing > falls through the cracks >=20 > dana >=20