feat: per-milestone due dates (next + upcoming)#88
Merged
Conversation
Replace the single --due-date with --next-due and --upcoming-due, one per open patch milestone (the next patch and the one after). Each date is applied whether the milestone is created by this run or already exists, so a run also corrects stale or missing due dates (e.g. an existing 34.0.1 with the wrong date). Adds a set_due helper (PATCH due_on), replaces the due_date dispatch input with next_due / upcoming_due, updates the README, teaches fake-gh to honour due-date PATCHes (journalled as `setdue`), and adds scenarios + unit tests covering create-with-due, set-due-on-existing, and per-flag validation. Major milestones (first beta) no longer take a due date. Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A run keeps two open patch milestones (next + upcoming). The old single
--due-dateonly fed the upcoming one, and only when it was freshly created — so:34.0.1) never got a due date from the script, andThis surfaced on
v34.0.0:34.0.1already exists with inconsistent dates across repos (server2026-06-25, activity none), unreachable by the old flag.What
--due-datewith--next-dueand--upcoming-due(one per open patch milestone). Same split for theworkflow_dispatchinputs (next_due/upcoming_due).set_due→PATCH due_on). Idempotent: re-running with the same dates is a no-op and fixes stale dates.Example:
Testing
run.sh— 20 scenarios. New/updated:due-date(next exists →setdue, upcoming missing → create-with-due),due-date-existing(both exist →setdueboth),bad-due-date(invalid--next-due→ exit 1).unit.sh— 16 checks incl. per-flag validation + header echo of both dates.setdue.Note
--due-dateis removed (not aliased). The auto-pipeline (release.yml→workflow_call) only passestag, so it's unaffected.