-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy: don't add a new release signing key shortly before a release #278
Comments
I guess this makes sense to a degree, but how do you propose we notify people? I don't think people will be regularly checking the readme for new keys, so no matter when we add people people probably aren't going to notice until their scripts break. At the moment the first notable change for the release is that the new key was added, I'm not sure we could highlight it more. Definitely something to consider going forward though. |
We so rarely add new releasers, and each time we have in the past they have been added during a non milestone release. Likely we should just focus on adding people for non milestone releases... so no transitions, semver majors, or security releases That way if people need an extra day or two to catch up with stuff it isn't a fire drill |
Seems like a good idea. |
@ofrobots I'm going to close this for now, but I am fairly confident this will not rpeat |
With
8.9.0
, we added a new releaser and a new release signing key shortly before the release. (Thanks @gibfahn for all your hard work in getting the release out of the door ❤️).I would like to propose we add new release signing keys well in advance of them getting used. Otherwise, any new binaries published with the new key seem like rogue binaries as downstream users/organizations haven't had a time to react to the addition of the new release key.
The text was updated successfully, but these errors were encountered: