A milestone groups issues and pull requests toward a target, usually a release, with an optional due date and a progress bar computed from how many are closed. BookNest's next release, 1.2.0, gets the sort fix, the author filter and the error documentation. gh 29 has no milestone command, so create it with gh api, then attach issues:
gh api repos/{owner}/{repo}/milestones -f title=1.2.0 -f due_on=2026-10-31T23:59:59Z \
-f description="Sorting, the author filter and error docs" \
--jq '"#\(.number) \(.title), due \(.due_on)"'
gh issue edit 1 2 5 --milestone 1.2.0
gh api repos/{owner}/{repo}/milestones \
--jq '.[] | "\(.title): \(.open_issues) open, \(.closed_issues) closed"'#1 1.2.0, due 2026-10-31T00:00:00Z https://github.com/binarybehemoth/booknest/issues/1 https://github.com/binarybehemoth/booknest/issues/2 https://github.com/binarybehemoth/booknest/issues/5 1.2.0: 3 open, 0 closed
GitHub 29 stores only the date of due_on and drops the time of day, as the output shows. Each issue or pull request can belong to one milestone, and a milestone to one repository, so cross-repository release planning belongs in a project (Project Boards) or a tracking issue (Task Lists). Name milestones after versions (Semantic Version Tags), keep only the next one or two open, and move unfinished issues forward instead of letting the date pass silently.