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 5220774f for ; Sun, 15 Dec 2019 05:17:17 +0000 (UTC) Received: (qmail 17563 invoked by alias); 15 Dec 2019 05:17:12 -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: 45033 Received: (qmail 13637 invoked by uid 1010); 15 Dec 2019 05:17:12 -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.1/25656. spamassassin: 3.4.2. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 4.549484 secs); 15 Dec 2019 05:17:12 -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: gggruggvucftvghtrhhoucdtuddrgedufedrvddtvddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjggfsehtkedttddtreejnecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeejledrudektddrheejrddu udelnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrg hfrdhnrghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Date: Sun, 15 Dec 2019 05:16:29 +0000 From: Daniel Shahaf To: Zsh Workers List Subject: Re: Test release: 5.7.1-test-1 Message-ID: <20191215051629.ikoezos6bsnirplf@tarpaulin.shahaf.local2> References: <8D05A1CC-D633-4027-9710-0E4D8E56C97C@dana.is> <189cf738-4029-49f3-b502-dc058e11eb63@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) dana wrote on Sat, Dec 14, 2019 at 22:32:57 -0600: > On 14 Dec 2019, at 21:58, Daniel Shahaf wrote: > > README shouldn't say "This is version 5.8. It is a stable > > release." yet. The tarball is 5.7.1-test-1, not 5.8, and it's a test > > release, not stable release; that's what README should state. > > Oh. I had just copied what we did for 5.7: > > https://github.com/zsh-users/zsh/commit/9dbde9e9c7d22ee0d301e4a2fecf97906d1ddce9 > > If that's undesirable, i'll add it to the release instructions later. Ah, I didn't realize there was precedent for that. I _still_ think -test- tarballs should not describe themselves as the final release, but if we have precedent for doing things differently then perhaps there's a good reason for that that I'm overlooking. > On a related note, i also wasn't clear on how the -dev- and -test- numbering > are meant to work. Previous first -test- releases have either reset the number > to 1 or incremented the last -dev- number (e.g., -dev-1 to -test-2). The > release instructions say -dev-$((i++)) and -test-$((++j)), which i guess means > start from -dev-0 and -test-1, but it's not quite explicit. Is that correct? Yes, that's the intended meaning, and yes, I could've written it more explicitly. > (If they do have different 'base indexes', why?) I just documented what I had determined to be precedent from looking at git history at the time of writing. I'm not aware of any reason beyond this. I do think, however, that the version number of master should increase chronologically. I assume most packaging systems would consider any test version number as larger than any (hypothetical) dev version because 'dev' < 'test' as ASCII strings (i.e., as determined by strcmp(3)); for example, Debian: $ dpkg --compare-versions '5.7.1-dev-9' lt '5.7.1-test-0' && echo yes yes $ This implies that the release after ${V}-dev-5 could be either ${V}-test-1 or ${V}-test-6, insofar as version number ordering is concerned. I don't have a strong preference between these two. > Lastly, should the 'latest version' on Sourceforge be updated to point to test > releases, or only stable ones? The instructions didn't make a distinction, so > i updated it, but that's another thing that might be made more explicit. Actually, I'd err on the side of *not* updating it, since it's what SF offers as the default download, and we don't want people to download test releases unless they opt-in to that. No fault to you for guessing wrongly — on the contrary, kudos for taking action and asking on-list afterwards — but I suggest that you revert this. You can do this by selecting zsh-5.7.1.tar.xz in the file manager and clicking the "Make this the recommended version" button in the UI (I don't remember the exact phrasing). If there's a separate "Recommended beta version" thing, we could use that. Otherwise, 5.7.1 should remain the recommended production/stable version until 5.8 comes along. > PS: You might've noticed that i also forgot to update the change log before > tagging; i can't blame that on confusion, i just messed up :( No worries. Just make sure it's documented clearly in the checklist for next time ☺ Cheers, Daniel