Everything

php

Home » Project » Newsgroups » php.internals » Public Tags of Releases »

Public Tags of Releases

php.internals

Niklas Keller

8 years ago

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

Joe Watkins

8 years ago

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:

Niklas Keller

8 years ago

>
> Afternoon,
>
> Tags are created in release branches, these branches should not be part of
> any workflow other than our internal one.
>

I'm not talking about branches, but tags. Updating these release branches
doesn't matter and is totally fine, as these are normal branches and thus
not deemed immutable.

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
>

Regards, Niklas

Sara Golemon

8 years ago

On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <me@kelunik.com> 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

Niklas Keller

8 years ago

>
> On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <me@kelunik.com> 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?
>

No, that'd be fine, too. But IIRC there have been re-tags instead of new
tags before.

> 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.
>

That "or whatever" should probably be covered in the release process
document(s).

> 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.

Correct, the tags are there, so people use them.

> 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*
>

Why not just use the release branch instead of tags for that phase? I don't
think having a lot of these useless tags is a good thing.

Regards, Niklas

Anatoliy Belsky

8 years ago

Hi,

> -----Original Message-----
> From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Tuesday, November 28, 2017 6:17 PM
> To: Niklas Keller <me@kelunik.com>
> Cc: PHP Internals <internals@lists.php.net>; Joe Watkins
> <pthreads@pthreads.org>; Remi Collet <remi@php.net>; Anatol Belski
> <ab@php.net>
> Subject: Re: Public Tags of Releases
>
> On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <me@kelunik.com> 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*
>

Tags and branches have a naming scheme, what only matters for a release right now is

- branching off
- tag
- do tarball
- do Windows build and zipball
- announce

By the current terms - there's no release until the announcement. Tags are a virtually internal thing. For a number of people the tarball is the actual release. The Windows builds are done from the tag, that's specific. The tarball is what includes generated files and goes to the mirrors, creating it before it's like putting a state under seal. Thanks to the fact it's open, more QA can be done. Thanks to the 2 day buffer, isues can be caught.

Till now all the QA, except security issues, is an open process. The open process has a huge advantage of having lots of eyes on what is happening and helps not less than valgrind. Tags are an intermediate link in that chain. There should be one tag in the end, any other intermediate states are available from the release branch. Years after - there's still one tag for one release, clearly named.

Regarding the technical side. There's `git fetch --prune --tags`, etc. Mirroring a repo assumes some level of expertise, it is not that terrible in the end. From my perspective, I don't see a real improvement in neither tagging in private or producing x different tags. From both technical and procedural side the current approach seems clear, flexible enough and good for QA at the same time.

Regards

Anatol

Jan Ehrhardt

8 years ago

Anatol Belski in php.internals (Tue, 28 Nov 2017 19:29:41 +0000):

>By the current terms - there's no release until the announcement. Tags
>are a virtually internal thing. For a number of people the tarball is
>the actual release. The Windows builds are done from the tag, that's
>specific.

FWIW: I am using the zip's at github, like
https://github.com/php/php-src/archive/php-7.2.0.zip

--
Jan

Johannes Schlueter

8 years ago

On Mi, 2017-11-29 at 12:09 +0100, Jan Ehrhardt wrote:

> FWIW: I am using the zip's at github, like
> https://github.com/php/php-src/archive/php-7.2.0.zip

Contrary to "official" release tarballs those don't contain generated
parsers etc. thus behavior might be different i.e. due to different
bison versions being used. (sohuldn't be, but happened in the past)
Also they don't contain ready to use configure scripts (for unix-like
systems) thus a (Linux/Unix/Mac) user needs right versions of auto
tools.

johannes

lists@rhsoft.net

8 years ago

Am 29.11.2017 um 15:37 schrieb Johannes Schlüter:

> On Mi, 2017-11-29 at 12:09 +0100, Jan Ehrhardt wrote:
>> FWIW: I am using the zip's at github, like
>> https://github.com/php/php-src/archive/php-7.2.0.zip
>
> Contrary to "official" release tarballs those don't contain generated
> parsers etc. thus behavior might be different i.e. due to different
> bison versions being used. (sohuldn't be, but happened in the past)
> Also they don't contain ready to use configure scripts (for unix-like
> systems) thus a (Linux/Unix/Mac) user needs right versions of auto
> tools

same applies to compilers, compiler flags and system library versions
anyways

# rebuild 'data_file.c' from current system libmagic starting with PHP
7.2 and when /usr/bin/php is installed
%if "%{version}" >= "7.2.0"
if [ -f /usr/bin/php ]; then
/usr/bin/php ext/fileinfo/create_data_file.php
/usr/share/misc/magic.mgc > ext/fileinfo/data_file.c
fi
%endif

# generate zend-vm when /usr/bin/php is installed
%if "%{version}" >= "7.2.0"
if [ -f /usr/bin/php ]; then
/usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=HYBRID
fi
%else
if [ -f /usr/bin/php ]; then
/usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=CALL
fi
%endif

# force use of system libtool and regenerate configure scripts
cat `aclocal
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4 >>
aclocal.m4
libtoolize --force --copy --quiet
cat `aclocal
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4

>build/libtool.m4

%if "%{version}" >= "7.2.0"
touch configure.ac
%else
touch configure.in
%endif
./buildconf --force

Johannes Schlueter

8 years ago

On Mi, 2017-11-29 at 15:43 +0100, lists@rhsoft.net wrote:

> Am 29.11.2017 um 15:37 schrieb Johannes Schlüter:
> >
> > On Mi, 2017-11-29 at 12:09 +0100, Jan Ehrhardt wrote:
> > >
> > > FWIW: I am using the zip's at github, like
> > > https://github.com/php/php-src/archive/php-7.2.0.zip
> > Contrary to "official" release tarballs those don't contain
> > generated
> > parsers etc. thus behavior might be different i.e. due to different
> > bison versions being used. (sohuldn't be, but happened in the past)
> > Also they don't contain ready to use configure scripts (for unix-
> > like
> > systems) thus a (Linux/Unix/Mac) user needs right versions of auto
> > tools
> same applies to compilers, compiler flags and system library
> versions 
> anyways
>

This is true, but usually has less impact. bison&co historically are
less stable than compiler support for language features we use.

Third party libraries used in extensions are another complex story.
Which is why we bundle some libs.

johannes

Rowan Collins

8 years ago

Hi,

I agree that tags should be treated as immutable, because that's what distinguishes them from branches. That's true of any VCS, but git has the added restriction that they're treated as global: tags from different remotes aren't tracked separately, they are all merged into the local namespace immediately.

On 28 November 2017 17:16:52 GMT+00:00, Sara Golemon <pollita@php.net> wrote:

>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*

The logical name for this would be "php-X.Y.Z-RC1": this is a Candidate revision which we believe is going to be tagged as Release. However, the current process abuses that term for late-stage test builds which are not actually release candidates. :(

Another alternative would be to simply increment the build number on the rare occasions a tag is withdrawn: if 7.2.2 was a bad tag, just release 7.2.3 instead.

Regards,

--
Rowan Collins
[IMSoP]

Stas Malyshev

8 years ago

Hi!

> 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.

That's not how git is supposed to work? If you syncronize the repo you
should get the new tag. If you cloned repo once and never update then of
course you don't get new tag, but you also don't get the fix...

> 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

But we don't have private repository? We have security repo but this one
is for security fixes and not for release work, in fact it doesn't even
have to be up-to-date with release, it's only for keeping/exchanging
security patches.

--
Stas Malyshev
smalyshev@gmail.com

Sara Golemon

8 years ago

On Tue, Nov 28, 2017 at 7:30 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

>> 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.
>
> That's not how git is supposed to work? If you syncronize the repo you
> should get the new tag. If you cloned repo once and never update then of
> course you don't get new tag, but you also don't get the fix...
>

Erm, actually no, it's not how git is supposed to work.

If you have an up to date checkout of php-src/master right now, it
contains the php-7.2.0 tag.
If Remi adds more commits (to fix something) and moves that tag to the
new head of the PHP-7.2.0 branch and pushes it, then anyone who HADN'T
YET synced php-src/master since this morning will get the new tag
fine, but you never will (not with a normal `git pull`, anyway). This
is because git will not change tags unless you explicitly tell it it's
okay to.

Moving git tags after they've been pushed to a remote (shared) repo is
as much a sin as force pushing. It shouldn't be done.

-Sara