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 57716eed for ; Tue, 18 Feb 2020 20:45:39 +0000 (UTC) Received: (qmail 13467 invoked by alias); 18 Feb 2020 20:45: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: 45467 Received: (qmail 6732 invoked by uid 1010); 18 Feb 2020 20:45:33 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-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.167.44):SA:0(-1.9/5.0):. Processed in 1.697318 secs); 18 Feb 2020 20:45:33 -0000 X-Envelope-From: schaefer@brasslantern.com 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.167.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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PmUG3xHxAzkOMKz+PhBvQrBZ8Yt+IZu4PkJ6eDq+D1Q=; b=KyjyoePHU+1uUGxMFsU5Vt5BXTsEwQ0usOf5WKQCJh5cibeVWmUIR0FUWWqAEKgjvd Ly/0KV70bChNS1Ed80OCrQrC6hjI/g8bSCEQqDjlEV/1XQN3kyxeVU5R7/eouHsjDlS6 8IWzEAVLbHv7lewbAKPTkzG2e/hyvcwI/SI0qqPD633SHww51xiPUMqfUE677oq2Zb/p WXwrxulr7reOUOlIppoBnQExx1DLuQ3iS3X1N9VwWEjJv8wKwMVBN1hc0HKXLSPcES2I kw3g7RbXaJkwksTUdM5WeXfCCBI2/oK0K0uYREtStBnSvp4k3IQlBWhGQcd7CwJb2qB2 1MhA== X-Gm-Message-State: APjAAAXxrvKjcS4Cqzby4x8HA8lNBhi5K7E3OqGUxPIJGErSsG/FjB2B m8ipdeZgXudyM3ZPkpakA4yOFwFYVDqrO2JDZspSLx3k/w9LVw== X-Google-Smtp-Source: APXvYqzDZphMtcX1MRhi372sV0BWt7Vj4UrNPkHJuaEOFp1/GFQV2OiyINTMOz886kh/47zWoQTXU/pEWwW/P4tbFkg= X-Received: by 2002:ac2:55a8:: with SMTP id y8mr11556364lfg.117.1582058696292; Tue, 18 Feb 2020 12:44:56 -0800 (PST) MIME-Version: 1.0 References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> <20200217091958.0fa9f1d8@tarpaulin.shahaf.local2> In-Reply-To: From: Bart Schaefer Date: Tue, 18 Feb 2020 12:44:44 -0800 Message-ID: Subject: Re: Plan for the 5.9 branch To: dana Cc: Daniel Shahaf , Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Tue, Feb 18, 2020 at 11:41 AM dana wrote: > > Right. All i'm really worried about personally are fixes for security issues > and the type of regressions we normally correct in .1 releases. At my $WORK we use the following approach, parts of which might be overkill for zsh-workers, but presented in case worth discussing: The current release is always a version number tag on the master branch, there are not branches for numbered releases. Each proposed change goes on its own branch created from master. This is rebased on master if necessary before merging with other changes. (In the zsh world this would probably mean creating a branch named for a zsh-workers sequence number.) Critical changes (post-release regression fixes, security issues, etc.) can go directly from these branches onto master for immediate release if necessary, at which time a new version tag is created on master. There's a development branch onto which anyone can merge/push pretty much anything, even if it's not on a proposed branch yet, to test conflicts/interactions, get feedback, etc. This is sort of what we do in zsh via vetting of patches on the mailing list. Right before a release, a staging branch is created, which is the master branch merged with whatever subset of the proposed change branches are ready. This is like the zsh*-test-N versions we've been publishing, it's used to QA the assembled changes before they go on the master branch, but it allows us to pick and choose which proposed changes actually go into a release if some are "more thoroughly cooked" than others. Changes that result from QA get revision tags on the staging branch. For release, the staging branch is merged back onto master and a new version tag is assigned to master. Then the staging branch is deleted, and not re-created until the next pre-release cycle. The development branch is usually sync'd up with the master branch at this point as well, although what that means is mainly that there's nothing on master that is missing from development. Unless there's some large unfinished project under way, it typically means the development branch is made the same as the current master, because anything else can be restored from the proposed change branches.