Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101202
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
Date: Wed, 29 Nov 2017 13:52:17 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <CAESVnVq4TQ02RYSWFiBMK132TVX4z8Xyk+QtwbWok7gpfJyg=A@mail.gmail.com>
References: <CANUQDCgePs2B3JrYhWGA3rMW9OM0tmnRpdinPs8=Zkt_vHYDUA@mail.gmail.com> <CAESVnVq4TQ02RYSWFiBMK132TVX4z8Xyk+QtwbWok7gpfJyg=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <585F3154-51CF-4AC7-98AC-B3C9FA71F949@gmail.com>
Subject: Re: [PHP-DEV] Re: Public Tags of Releases
From: rowan.collins@gmail.com (Rowan Collins)

Hi,

I agree that tags should be treated as immutable, because that's what dist=
inguishes them from branches=2E That's true of any VCS, but git has the add=
ed restriction that they're treated as global: tags from different remotes =
aren't tracked separately, they are all merged into the local namespace imm=
ediately=2E


On 28 November 2017 17:16:52 GMT+00:00, Sara Golemon <pollita@php=2Enet> w=
rote:
>Okay, that's a reasonable middle ground=2E  We could tag as
>php-X=2EY=2EZ-something Tuesday, then tag again as php-X=2EY=2EZ on Thurs=
day=2E
>That would only add one step to the release process at the minor cost
>of having more tags=2E *shrug*

The logical name for this would be "php-X=2EY=2EZ-RC1": this is a Candidat=
e revision which we believe is going to be tagged as Release=2E However, th=
e current process abuses that term for late-stage test builds which are not=
 actually release candidates=2E :(

Another alternative would be to simply increment the build number on the r=
are occasions a tag is withdrawn: if 7=2E2=2E2 was a bad tag, just release =
7=2E2=2E3 instead=2E

Regards,

--=20
Rowan Collins
[IMSoP]