Versions and changelog

Group a project's milestones into versions (1.0, 1.1…) and have AI write each version's changelog, ready to copy.

The version's changelog, written for you. In the Versions tab you group the project's milestones into versions: create 1.0, add its milestones right from the list, and Hilbana's AI writes its changelog from the work done in them, ready to copy. Watch in the feed →

A version groups several milestones of a project under a name such as 1.0 or 2026.10. It answers two questions: what goes into the next release, and what changed in it. The second one is answered by the changelog, which AI writes from the work done in those milestones.

What it is

  • Versions belong to each project: every project has its own, with a name, a color and an order you decide.
  • A milestone belongs to one version at most. The ones without a version are listed separately, under “No version”.
  • A version’s progress is the sum of its milestones: how many there are and how many of their issues are done.

The Versions tab

Every project has a Versions tab, between Cycles and Docs. It shows the versions in order, each with its milestones and progress bar, and the milestones without a version at the end.

From there you can:

  • Create a version with “New version”: name and color.
  • Rename it by typing over its name, and change its color by clicking the color dot.
  • Reorder it with the up and down arrows.
  • Distribute the milestones: each milestone has a version picker on its right. Use it to put the milestone in a version, move it to another one or remove it. If you type a name that doesn’t exist, the version is created on the spot.
  • Delete it. Its milestones aren’t deleted: they’re left without a version.

Clicking a milestone’s name opens its page. The version can also be picked there, in the Version field.

The changelog

Once the milestones are in place, click Generate changelog on the version. AI reads each milestone’s closing summary and writes release notes in markdown, grouped by feature rather than by milestone, and written for the people who use the product. They’re saved with the version, so the whole team sees them.

  • Copy puts the markdown on your clipboard as is, ready to paste into your public changelog, a GitHub release or an email.
  • Regenerate writes it again, for example after closing more work or moving milestones between versions.

Where it comes from

The changelog is written from the milestone summaries, not from individual issues. If a milestone doesn’t have a summary yet, it’s generated on the spot:

  • If the project has GitHub or Bitbucket connected, from the code changes in its merged PRs.
  • Otherwise, from its done issues (title and description).

A milestone with no merged PRs and no done issues has nothing to summarize: it’s left out and the version tells you which one. If none is left, nothing is generated.

The text is written in the language of whoever generates it (the one in their profile, English or Spanish), even if the milestone summaries are in another one.

Permissions

  • Creating, editing, reordering and deleting versions, distributing milestones and generating the changelog require write access to the project.
  • People who can only read the project see the versions and their milestones, and can copy the changelog.

Related: Projects · Initiatives and products · Project report.