An issue list answers what is left. It rarely answers when, because a GitHub issue typically carries no dates. That one gap is why so many release plans end up in a spreadsheet parked next to the repository.
A billing release makes it concrete: a schema migration for the subscriptions table, a payment provider webhook handler, a seat-based pricing calculator, the billing settings screen, and a copy change on the pricing page.
The order isn't in dispute. The migration goes first, the handler and the calculator wait on it, the settings screen waits on the handler, and the copy change lands whenever.
What GitHub already handles
Sub-issues give a release a hierarchy. The Relationships section of any issue accepts blocked by and blocking links, up to fifty of each. Both went generally available during 2025, both are on every plan including Free, and the CLI sets them too.
That puts the ordering in the repository, next to the work. What it does not put there is a date. The structure is recorded; the schedule is not.
Adding dates through a project
Dates come from projects rather than from issues. Add the work to a project, switch a view to the Roadmap layout, then open Date fields and pick which field drives the start date and which drives the target date. Roadmaps position items from your custom date and iteration fields, reusing any the project already has. Teams running iterations may not need to add a field at all.
Filled in, the release runs about three weeks: three days of migration at the front, the handler and the calculator in parallel once it clears, the settings screen behind the handler, the copy change last. The calculator is the long pole, which is worth knowing in week one rather than week three.
For one repository with a handful of dependencies, that solves the planning problem at no extra cost.
Where it stops
Estimates move. Suppose the migration needs an unscoped backfill and runs six days longer. Dragging that bar changes exactly one thing: that bar.
Everything waiting on it stays put, and two of those items now begin before the schema they depend on exists. The chart shows a schedule that cannot happen, and marks it no differently from one that can.
The blocked-by links are already recorded and they change nothing here. The roadmap layout positions bars from date and iteration fields alone, so no relationship reaches the schedule: no redraw, no warning, no shift. Someone re-drags the chain by hand, in dependency order, every time an estimate changes. Setup takes twenty minutes; the re-dragging never stops.
The same issues, on a Gantt chart
Ganttify reads the repositories directly and builds the timeline from what's in them. Milestones arrive as collapsible groups, issues become time blocks, and the dependency already recorded in GitHub is drawn as an arrow that constrains the dates rather than annotating them.
That is the same slip as before. The migration still runs six days long, but the handler, the calculator and the settings screen move with it, and the release date lands on the 31st instead of the 24th. Nothing was dragged by hand, and no arrangement of bars is left claiming something impossible.
Edits travel in both directions. Dragging a block to a new date writes that date back to GitHub, and closing an issue in GitHub shows up on the chart. The chart stays a view of the repository rather than a second copy that drifts out of date.
Repositories are chosen rather than assumed, so a release split across frontend, API and infrastructure repos lands on one timeline instead of three. Filtering works the way the issue board does, by any combination of labels, assignees, or milestones, which matters once a chart covers more than one team's work.
The timeline also lives outside GitHub, so it can be published as an always up-to-date, read-only Gantt chart, ready to share with clients and management. They get the date without needing repository access, and what they open is never a stale screenshot.
Trying it
The GitHub integration is in invite-only beta as this is written. Join the waiting list and we'll send an invite as we widen access.