Skip to content
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

x/build: consider pushing open backport issue milestones automatically at start of each month #41323

dmitshur opened this issue Sep 10, 2020 · 1 comment


Copy link

@dmitshur dmitshur commented Sep 10, 2020

Right now, the milestones of open backport issues that did not get included in a given minor release are automatically bumped to the next minor release milestone by releasebot at the end of a successful release stage:

Since we generally don't try to include more fixes in a minor release after the start of a month (aside from ones that have release-blocker label, which must be considered), it should be more accurate and clear to push the milestone to the next one at the start of the month.

However, when considering this, we need to be careful so that we don't accidentally land another fix after a month starts and forget to move the milestone of corresponding issue back to the correct previous one.

This issue is likely best to address as part of overall release automation, tracked in #40279 and #29205. /cc @toothrot

Thanks to @mundaym for suggesting this in

/cc @toothrot @cagedmantis @andybons

Copy link
Contributor Author

@dmitshur dmitshur commented Oct 22, 2020

I've considered this idea during the development and release of Go 1.15.3 and 1.10.14 releases recently.

Those releases were not made at the beginning of the month because there were release-blocking issues open that needed more time to be resolved. During that time, we had an opportunity to make progress on additional backports.

I think it was helpful that it could be done without needing to move the milestone back on the issues that were fixed (and avoiding the risk of forgetting to do that).

Based on that, it seems the benefit of implementing this change is reduced. I welcome other feedback; I wanted to share my observations so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant