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 09298bcf for ; Wed, 19 Feb 2020 15:22:59 +0000 (UTC) Received: (qmail 1307 invoked by alias); 19 Feb 2020 15:22:50 -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: 45476 Received: (qmail 558 invoked by uid 1010); 19 Feb 2020 15:22:50 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f177.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.208.177):SA:0(-1.9/5.0):. Processed in 1.754711 secs); 19 Feb 2020 15:22:50 -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.208.177 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=IEjfvlu57wCyWWr8vpmsqg35UZVdgzCYH/jsiq2QohI=; b=UFTX3Dq8eFeRjkrIG/TlfTBtB2X3Z6qcjBF+P7Jamlh/lfZAJwrm2VJs5aXz0Tknzy wSPctrQB+JCVHzysx3pGc7f4Yqn4XMkYaUVg64AhNKnSEA7gjmaRTTkHvmqBLMklmRZk 8awjC4jU4g75VzuVeSzY3wdIQ+zh5URFcDYYZ2E4TuQ35EYNMGecYFA9IVvRm8/p2j96 OjW0RhgRhZKSUKGVlmNaElrh/LEX1ixfJg+6xhogZh7Cyof9IhqhjiNVYAW0MrIcM103 CmFW+7HPEX2Y4o0/apeEw8ZZMqIMwe+ioaERqDQ9HOeaYfI2Tbd/8hb2XQS9syXIm02o nfPg== X-Gm-Message-State: APjAAAUrnJWG1/PuY89p8jsPZTh6f9Z2A/dUiNvXIp+TjKwswdXrIN8W Aj8siV0hjmHVNSXTL7sk3DzOK4b0BEA0P5G9pBj/Ys8ZtXw= X-Google-Smtp-Source: APXvYqw96El8Rrczq7UOa6Bt46lZa/AmyK2QpRoQ39HBQwJdwsbsKQLFIOyn/KdJBcDfbWuIvpazs+614O+9n4xstVM= X-Received: by 2002:a2e:9143:: with SMTP id q3mr15400659ljg.199.1582125732376; Wed, 19 Feb 2020 07:22:12 -0800 (PST) MIME-Version: 1.0 References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> <20200217091958.0fa9f1d8@tarpaulin.shahaf.local2> <20200219103205.0aa6f13f@tarpaulin> In-Reply-To: <20200219103205.0aa6f13f@tarpaulin> From: Bart Schaefer Date: Wed, 19 Feb 2020 07:21:58 -0800 Message-ID: Subject: Re: Plan for the 5.9 branch To: Daniel Shahaf Cc: dana , Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Wed, Feb 19, 2020 at 2:32 AM 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? If it's a bug such that the feature does not function usably in some circumstances, or causes a crash, compatibility isn't an issue. If it's a behavioral difference where the feature does something usable/useful but inconsistent with the intended behavior, then the compatibility question arises. The longer the feature has been "in the wild" the more likely we are to need to keep compatibility. For two months I wouldn't be especially concerned; two years and it becomes serious. I can't think of a better approach than to poll a few user channels (zsh-users, /r/zsh, whatever) to get a feel for how many people are depending on the anomalous behavior and whether the repair would be preferable. Other considerations are how easy it is to make a run-time decision about which behavior is present (testing a version number is not an "easy" test in this situation).