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 2d6625a2 for ; Wed, 19 Feb 2020 10:32:49 +0000 (UTC) Received: (qmail 21135 invoked by alias); 19 Feb 2020 10:32:44 -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: 45475 Received: (qmail 18616 invoked by uid 1010); 19 Feb 2020 10:32:44 -0000 X-Qmail-Scanner-Diagnostics: from out1-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(66.111.4.25):SA:0(-2.6/5.0):. Processed in 0.717194 secs); 19 Feb 2020 10:32:44 -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: gggruggvucftvghtrhhoucdtuddrgedugedrkedtgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfgjfhfogggtgfesthhqre dtredtjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgv lhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudejkedrjedrudekleenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Date: Wed, 19 Feb 2020 10:32:05 +0000 From: Daniel Shahaf To: dana Cc: Zsh hackers list Subject: Re: Plan for the 5.9 branch Message-ID: <20200219103205.0aa6f13f@tarpaulin> In-Reply-To: References: <20200216111511.73ea28fa@tarpaulin.shahaf.local2> <3FA782D3-CBCF-4D49-AF9E-55C63A05ECC1@dana.is> <20200217091958.0fa9f1d8@tarpaulin.shahaf.local2> 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 Tue, 18 Feb 2020 13:40 -0600: > On 17 Feb 2020, at 03:19, Daniel Shahaf wrote: > On 17 Feb 2020, at 03:19, Daniel Shahaf wrote: > > What degree of support/compatibility promises will they > > come with =E2=80=94 comparable to a -dev/-test release or to a regular = release? Etc. =20 >=20 > Re: compatibility, as a rule i would suggest that patch releases under th= is > system should not contain anything that Debian/Ubuntu wouldn't be comfort= able > pulling into one of their (non-rolling) releases. Maybe that's slightly t= oo > strict in practice, but i think that's a reasonable goal at least. >=20 > Re: support, i'm not sure i even know what promises we make for stable > releases now, lol For one, we implicitly promise compatibility: if something works in=C2=A05.8, users are allowed to assume it will work in=C2=A05.9 as well. (Which by extension means bugs in it will be considered release blockers) 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 the feature hadn't appeared in a release, the answer would be an unequivocal "Yes". Given that it has appeared in a release, do we promise to users of that release that we won't break compatibility with what they have? If we don't promise that, fewer users will install the additional releases; but if we do make that promise, we'll have less time to find bugs in features before we're committed to support those features going forward. Cheers, Daniel