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
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
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
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
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
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
tonot 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
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 Releasesit'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
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
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
Am 29.11.2017 um 15:37 schrieb Johannes Schlüter:
FWIW: I am using the zip's at github, like
https://github.com/php/php-src/archive/php-7.2.0.zipContrary 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
Am 29.11.2017 um 15:37 schrieb Johannes Schlüter:
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
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.
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]
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
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