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 b054e7e1 for ; Mon, 17 Feb 2020 02:48:38 +0000 (UTC) Received: (qmail 21222 invoked by alias); 17 Feb 2020 02:48:33 -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: 45444 Received: (qmail 24445 invoked by uid 1010); 17 Feb 2020 02:48:33 -0000 X-Qmail-Scanner-Diagnostics: from mail-yb1-f182.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25724. spamassassin: 3.4.2. Clear:RC:0(209.85.219.182):SA:0(-1.9/5.0):. Processed in 1.380409 secs); 17 Feb 2020 02:48:33 -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.219.182 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=PtDbnwipNxbRA3zzDzM8ltoM7QvBaJ1YxUzXAn2/VrY=; b=FOHhCcXFw8PINFYmnGhKpghEp8mGRN2pVAHJrEHe8OP8fTkP+ZoB68U1qI4DyEJL0R 7TNC6PdeV9p5Ed3pEn4hywQCCF+/WDk+CZGl2J+nhpXlzs2FbxrR1KSWncRuHa3I3mpF qZlPVLkB4M+XoTDQW0PHz9VFl9G18g/BKWNrbU5YTCsbJf/Jm2oZqn/NhiNOvGvwSuBn Fen8lIEQJQgt/fc3A+qOgHpEZczH/wLWQKjrclAETe97eQMLuqgIRBEHC3IWMciEThil ruBWG8rszEB+N9vf0BmNmS6UoUdsdCvm+PKE+F6SGgqxO1j+dplVcKT6nZitLvJRTWYq 6sOA== X-Gm-Message-State: APjAAAVUhUf8yhO2iFXAhXFp4ALO+Z/Lp4W6w6qHFedd+P27ukXlchtR PwSVzd0E3osb+9+hy8rLvRCreQ== X-Google-Smtp-Source: APXvYqxgRrEVF9p6uvcQYAdIlsls6E56NjQdGBqPeirwsDPTvFj4RAviUk7LLKl/9Cn7gu+LwIfiSQ== X-Received: by 2002:a25:4455:: with SMTP id r82mr12415164yba.103.1581907679190; Sun, 16 Feb 2020 18:47:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Plan for the 5.9 branch From: dana In-Reply-To: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> Date: Sun, 16 Feb 2020 20:47:56 -0600 Cc: Zsh hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> To: Daniel Shahaf X-Mailer: Apple Mail (2.3608.60.0.2.5) 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. 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 = those fixes and release 5.9.1 or whatever. Oliver pointed out before that nothing stops us from back-porting stuff = and releasing patch versions now, but i think the important thing is to have = a standardised process for it. It makes the releases go smoothly, and it = helps everyone make sense of the repo and the version history. And obv we'd = document the process somewhere for anyone who might get confused. 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-ports would be infrequent, and presumably it'd fall on the RM to make sure = nothing falls through the cracks dana