Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101182
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.217.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_nKjKD6H79aCetw3GqcvvGhgq0vKxA9+rnXrVOkc_jasA@mail.gmail.com>
References: <CANUQDCgePs2B3JrYhWGA3rMW9OM0tmnRpdinPs8=Zkt_vHYDUA@mail.gmail.com>
 <CAL=_i_ko8s6R5+UXtDi7n-yYshJpiig9YAL06NJcdwrQyRRAqA@mail.gmail.com> <CAL=_i_nKjKD6H79aCetw3GqcvvGhgq0vKxA9+rnXrVOkc_jasA@mail.gmail.com>
Date: Tue, 28 Nov 2017 17:04:26 +0100
Message-ID: <CAL=_i_n2=vbk33W_gavWAJS38nr3GgtG0mu=GT8G0JQrA_qvBg@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP internals <internals@lists.php.net>, Sara Golemon <pollita@php.net>, Remi Collet <remi@php.net>, 
	Anatol Belski <ab@php.net>
Content-Type: multipart/alternative; boundary="94eb2c094cca66b8a5055f0d2c3b"
Subject: Re: Public Tags of Releases
From: pthreads@pthreads.org (Joe Watkins)

--94eb2c094cca66b8a5055f0d2c3b
Content-Type: text/plain; charset="UTF-8"

Oh and private repositories suck, we already have a headache with security
fixes because of strange flow and secrecy, we simply don't need or want
more of that.

Cheers
Joe

On 28 Nov 2017 5:02 pm, "Joe Watkins" <pthreads@pthreads.org> wrote:

Afternoon,

Tags are created in release branches, these branches should not be part of
any workflow other than our internal one.

It's problematic to tag other than publicly, anywhere we create these tags
is public and presumably would cause the same problem for those people who
choose to use release branches in their workflow.

Cheers
Joe

On 28 Nov 2017 4:55 pm, "Niklas Keller" <me@kelunik.com> wrote:

> Morning,
>
> 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.
>
> 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.
>
> 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.
>
> Regards, Niklas
>

--94eb2c094cca66b8a5055f0d2c3b--