Zum Inhalt

From the fix to the release

← All features

Apps and integrations reach their users with a release, not with a merge. So an issue stays open until the fix is released.

A fixed issue, from the merge to the release: The maintainer merges a pull request with Fixes #12. issue-lifecycle.yml labels the issue fixed-in-next-release and comments that it closes with the next release; it stays open, since users don't have the fix yet. When the maintainer publishes the release v1.2.0, the lifecycle comments with the link to the release, closes the issue and files it under the milestone v1.2.0, and the reporter is asked to update. When the reporter comments within 30 days that it is still broken, issue-assistant.yml lets the AI read the comment and reopens the issue with needs-triage; after thanks or a question, it stays closed.A fixed issue, from the merge to the release: The maintainer merges a pull request with Fixes #12. issue-lifecycle.yml labels the issue fixed-in-next-release and comments that it closes with the next release; it stays open, since users don't have the fix yet. When the maintainer publishes the release v1.2.0, the lifecycle comments with the link to the release, closes the issue and files it under the milestone v1.2.0, and the reporter is asked to update. When the reporter comments within 30 days that it is still broken, issue-assistant.yml lets the AI read the comment and reopens the issue with needs-triage; after thanks or a question, it stays closed.

  1. A pull request names the issue it fixes with Fixes #12, as usual. When it is merged into the default branch, the issue gets the label fixed-in-next-release and a comment: fixed by the pull request, closes with the next release. Only a closing keyword of GitHub fixes an issue: Fixes, Closes or Resolves in any of their forms, before #12, owner/project#12 or the address of the issue, or a link that a maintainer makes by hand in the box Development of the pull request. An issue that the pull request only refers to, with Refs #12, See #12 or a link, keeps its labels and stays open, and so does one that the description names after words that say otherwise, such as This doesn't close #12 or Partly fixes #12, which GitHub links all the same: a negation such as not, never or doesn't, or partly or partially, that governs the keyword: right before it, or with only yet, fully, completely, entirely, totally, quite, really, actually, necessarily, alone, by itself or on its own in between, as in does not yet fully resolve #12, or through an infinitive of an intent or an ability, as in is not meant to close #12, doesn't try to fix #12 or will not be able to resolve #12. Any other word, a dash or a comma in between ends the negation, so a description of the bug before the fix still fixes it, as in The cache didn't refresh and this fixes #12 or So it doesn't crash anymore - fixes #12, and so does a negation as an emphasis, as in Not only fixes #12. The summary and the log of the sweep name each issue that stays open so. A maintainer can also set the label by hand, for a fix without a pull request. The morning sweep catches a merge whose run failed, up to 14 days later and however many pull requests the repository merged since; if a release ships the fix by then, the issue closes with it at once, without the comment.
  2. When a release is published, every issue with the label whose fix it contains closes as completed. A comment links the release and asks the reporter to update. It is the first final release, no draft or pre-release, that was published after the last fix was merged and contains every fix, so an issue that got its label late still closes with the release that shipped its fix. A label that a maintainer set by hand, for a fix without a pull request or after one that fell short, waits for the next release after it. Only this repository's pull requests count: one of another repository that names the issue with Fixes owner/project#12 neither keeps it open nor appears in the comment. The issue is filed under the milestone of the release, such as v1.2.0, which the assistant creates, closed, when it is missing; its page lists everything that the release fixed.
  3. If the reporter comments within 30 days that the problem persists after the update, the AI reads the comment and the issue reopens. Thanks or questions keep it closed. The AI reads up to two comments of the reporter after each release, as release_replies in config.toml says; a maintainer reads the rest. The comment of the release names the days of reopen_after_release_days, so that it promises only what happens. On a muted issue no AI reads the comment: the comment of the release asks the reporter to write for the maintainers instead, and a comment of theirs, at any time, gives the issue needs-triage, so that the digest lists it under Waiting on the maintainers and the sweep doesn't lock it until a maintainer answers.

A feature request had no problem to fix, so its comments say what was implemented: Implemented by #43, at the merge, and update to this version to use it. If something is missing, write a comment here, at the release. An issue is a feature request when it has the label enhancement or the issue type Feature, and not the label bug; every other issue, also one without a kind, hears of a fix. The gallery of the comments shows both in every language. The AI that reads the reporter's comment after the release reopens a feature request when what it asked for is still missing or doesn't work, and keeps it closed for wishes beyond it, which belong in a new issue.

The fixes of an issue are the pull requests of the repository that close it, as step 1 says, and were merged into the default branch at most 14 days before its label, the longest that the sweep takes to set it, and an hour more for the run of the sweep. A fix that a release closed the issue with before it was reopened didn't help, so neither that release nor the fix counts again; any other reopening, such as of an issue that GitHub closed at the merge, keeps the fixes:

Which release closes a fixed issue: For an open issue with the label fixed-in-next-release, the assistant looks for its fixes: pull requests of this repository into the default branch that name it, merged at most 14 days before the label, leaving out those that a release closed the issue with before it was reopened. With fixes and a label that the assistant set, the first final release published after the last of them was merged that contains them all closes the issue, also one published before a late label. With fixes and a label set by hand, it is the first final release after the label that contains them all. Without fixes, the first final release published after the label closes it. Drafts and pre-releases never close an issue.Which release closes a fixed issue: For an open issue with the label fixed-in-next-release, the assistant looks for its fixes: pull requests of this repository into the default branch that name it, merged at most 14 days before the label, leaving out those that a release closed the issue with before it was reopened. With fixes and a label that the assistant set, the first final release published after the last of them was merged that contains them all closes the issue, also one published before a late label. With fixes and a label set by hand, it is the first final release after the label that contains them all. Without fixes, the first final release published after the label closes it. Drafts and pre-releases never close an issue.

GitHub closes linked issues when a pull request is merged unless the repository turns this off: under Settings → General → Issues, clear Auto-close issues with merged linked pull requests. A repository without releases sets close_with_release = false in config.toml.