On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <m...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
