3.3Changelogs from tasks

Release notes assembled from commit messages read like a repository, because they are one. "Fix null deref in AISpawner" is not a line any player wants, and the two lines they *do* want are buried among forty of those.

So the changelog is built from tasks instead. When you cut a release, USourceControl works out which commits are in it and lists the tasks those commits closed. You get notes written in the language of the work.

What defines the range

• The start is the commit sequence number of the previous release on the same lineage. Both release paths count: a Forge build and a desktop publish are equally a release, and consulting only one would re-list everything the other already shipped.
• The end is the commit the build was made from.
• The lineage is the branch or edition being released.

  seq   19    20    21    22    23    24    25
         │           │           │     │
      release      closes      closes  │  closes
        1.2         #31         #28    │   #35
         ▲                             ▼
         └──────────── range ──────────┘

  1.3 release notes:
    · Enemy stagger pass          (#31)
    · Fix T-pose on death         (#28)
    · New main menu layout        (#35)

Why lineage is not optional

Sequence numbers are project-global. A console edition that has been frozen for certification for six weeks still shares its numbering with the main game, which has moved on.

A range without a lineage filter would therefore sweep up everything the main game did during the freeze and put it in the console build's notes. So the lineage is part of the range, always, and an unresolvable one is an error rather than a quiet fallback to main — answering with the main game's changelog looks like a valid answer while being exactly the wrong one.

The changelog appears on the release in the desktop app's Releases view, ready to paste into a store page or an announcement.