Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101188 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52228 invoked from network); 28 Nov 2017 17:16:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Nov 2017 17:16:57 -0000 Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.216.193 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.216.193 mail-qt0-f193.google.com Received: from [209.85.216.193] ([209.85.216.193:35973] helo=mail-qt0-f193.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 41/88-26862-70A9D1A5 for ; Tue, 28 Nov 2017 12:16:55 -0500 Received: by mail-qt0-f193.google.com with SMTP id a16so782620qtj.3 for ; Tue, 28 Nov 2017 09:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golemon-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IMzxGWyvQXWcBBkO0FzIWFb0pRj3naM0tB4wc8XdZVE=; b=qAsC90Id9jDMzYl4cJfSPIch426PqdCK0Vp++35ZPCNWHBGVWflQH/194Zr8Rhk4cC JVRur2nI+MnVOKg6XLz8+yyKscqk2V/IZl87EzfVfOKiKX0NvKQGaZohDnIwgzzjX7qu r009wAn3TGrCvSD2ysEtngaP9St0yMT/IKKt5I8ekZrINvSI2JXYGOHqbkPAKUxMQcr0 3T4uOWlz9+smYqFofBDDiNgj9XLEAb0WoMVLyjAfalvcxF3YlfDo8KzWyQssFNAxAoVd ic3+P/ynsB5X27bY4HJL6nll6uDanQaTXRQsm47pH30TYUleCza4uCOTlZaRgz9XBxGe vRPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IMzxGWyvQXWcBBkO0FzIWFb0pRj3naM0tB4wc8XdZVE=; b=jQRbHU4GDWLWhdPRI2qw6X6m5JvvzItcZ3I8fTmjEMzBa/q2hWD4ml6BA6SpXra5rV MKbUxs2tM6FHL0djb3LQ0Wu3dQw2GduMye+18yIUkeNKHueBZJ7ChNLXdPY7SJzV7aI6 7R1nqvM6UpK7LNcV/IULwgLplTX7jyEO2jmcTmkh9IeljuaWCdy44a/c9HOI3rwH4u11 /JTLBWjuRA67GFsFVuSLZDByE9NrpSejuxOy0V2x1ueB5XqnM8ltPlVfnuWCd9YdCQM9 dTnEDNxb0EtF6sZh6fOJJ/Af3WT3K/zWoUNf0QWxqPsOF4GMbbN1XeKsSHjiYZDHQNPH fDFA== X-Gm-Message-State: AJaThX7ZVdZQxkAWeUrYFsd6cmXSAVZJWD6yQCYAxnHN388lZjtE8M8N QS0fgIZd7JPRlXBIwMQTT+OCspl1jrKGR2hIUbqhXQ== X-Google-Smtp-Source: AGs4zMaLyg/4o+H8yY5BZw4FdSMOoAzCP5CX0geC8w7MAoeLG6BG8GLkA9DY8er7UHuA1nGOI8hgCFlLC/E0aIB+fbc= X-Received: by 10.200.25.207 with SMTP id s15mr65516534qtk.94.1511889413071; Tue, 28 Nov 2017 09:16:53 -0800 (PST) MIME-Version: 1.0 Sender: php@golemon.com Received: by 10.12.158.145 with HTTP; Tue, 28 Nov 2017 09:16:52 -0800 (PST) X-Originating-IP: [206.252.215.26] In-Reply-To: References: Date: Tue, 28 Nov 2017 12:16:52 -0500 X-Google-Sender-Auth: MecNXCHbrCQkbloT6bI2RJhOj_s Message-ID: To: Niklas Keller Cc: PHP Internals , Joe Watkins , Remi Collet , Anatol Belski Content-Type: text/plain; charset="UTF-8" Subject: Re: Public Tags of Releases From: pollita@php.net (Sara Golemon) On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller wrote: > it's the current practice to tag releases publicly two days before release > and then do the final QA phase. Could we please stop that? > > If there's a mistake that needs to be fixed and that's detected within these > two days, a re-tag needs to happen. If the old tag is deleted and a new > modified tag is published, all cloned Git repositories that already received > the old tag will keep the old tag and never receive the new tag unless the > old tag is manually removed first. That's problematic. > Agreed that tags shouldn't be moved once pushed, but is assigning a new version tag really that terrible? Example: php-7.2.0 tag was just pushed by Remi for the release on Thursday. If we do find a show-stopper bug, we can patch it and push php-7.2.0-pl1 or whatever. Not a hill I need to die on either way, but I don't see the early push as necessarily a bad thing. Indeed, I know there are users who look forward to the early tag to start their builds ahead of time. These parties then serve as a warning shot for that two-day cooling period. Could they build from branch before then? Yeah, but in at least one of those cases, I know that the presence of that tag is what got them doing it in the first place. > If there won't be a re-tag but a new tag name instead, there's no reason to > not see the tagging as release instead of the release announcement two days > later. > Apart from the windows builds, and those pre-builders mentioned above. > If tags are necessary for the final QA phase and the QA phase should happen > before release, then these tags shouldn't be public, but in a private > repository instead. If tags aren't necessary, then the QA phase can use a > different tag or just a commit reference and the release announcement can > happen directly after the tagging. > Okay, that's a reasonable middle ground. We could tag as php-X.Y.Z-something Tuesday, then tag again as php-X.Y.Z on Thursday. That would only add one step to the release process at the minor cost of having more tags. *shrug* -Sara