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