## Cabal 3.16 release post mortem (draft)

* release issue: https://github.com/haskell/cabal/issues/11010

* Our technology for producing releases seem to work great (at least from Artem's, the manager this time, perspective): team work of the release manager determining the tasks and a group of volunteers from the team who pick up individual tasks.

* One worry is that we may try harder to extend the pool of volunteers in the future.

* It's great to have contributions from Matt around numerous issues and @chreekat for GitLab CI including binaries.

* We tried something new this time: cutting the branch later than usual.
* Challenge: the earlier we cut the brunch, the more features will be missed or require backporting.
* Prompt: let's try to cut the branch as late as possible.
* Insight: some items on the release check-list can be pulled up, so that they happen before the branch. See the comments on the release issue on specifics.
* Overall it seemed to work well.
* I think Brandon said there are some downsides, ie there's some interaction with the bootstrap step. We should discuss it.
* If all good, we should edit the checklist to make the change permanent.
* Experience: this did come at a price. Because forking was moving around we failed to account for all the necessary PRs: Artem thought some PRs made it before the fork while they didn't (the release CI update), and for some PRs backports être created but not merged before tagging (AArch stuff).

* How to structure release-notes and/or the announcement.
* Perhaps we should improve changelog-d to allow us a richer structure than just significant vs. "other changes".
* Some examples:
* grouped changes by topic for 3.12.1.0: discourse.haskell.org/t/cabal-install-3-12-1-0-and-accompanying-libraries-released/9830.
* grouping by the type of change for 3.14: blog.haskell.org/ghc-9-12-cabal-3-14#cabal-3-14
* Hécate advocated for a more sophisticated structure with "unresolved" and maybe something else (see the 3.14 example by the link above).
* Do we have a template? Should we have one? We could say it's optional so that the manager feels more freedom in this but having a template could be of help for someone preferring to reuse the common wisdom developed over past releases.
* GitHub Copilot suggests:

> For user-friendliness, consider “Breaking Changes,” “New Features,” “Improvements,” and “Bug Fixes” as headings,

I wonder how complete and orthogonal this classification. It looks good on the surface. —This is more or less what I had already planned for changelog-d (Brandon)
* We have github labels like "type: bug", "type: enhancement". Maybe they should be revised according the classification above. And then there should be a process allowing to carefully thread these through the whole pipeline: issue/pr/tiny-changelog-file/release-notes.
* We need to listen to users too. SM on Matrix had some feedback about changelogs (and how he fancies them — his software has very good changelogs) but alas I did not take note at the time. (f-a)

* uploading artifacts: bad
* few ative people have rights (Franccesco, Brandon, Artem don't)
* Mikolaj discovered he can't do it either because of the infra revamp
* we should improve here...

* release checklist should be clearer what tasks need to be done for Cabal-hooks and in what kind of releases; e.g., now it doesn't mention Hackage candidates

* we had to redo tags because the copyright years were not updated
* that's okay: mistakes happen. This emphasizes importance of double-checking.

* no one knows how to designate a pre-release. It's weird for a pre-release to have a normal version number like 3.16 0.0.

* what a debucle it was... heisenrelease!..
* whoever does it next, decide in advance if it's a release or pre-release. if the latter, the version shouldn't look like a normal version

* HLS debucle: we didn't coordinate with the HLS team and the release turned out incompatible with existing HLS. See https://github.com/haskell/cabal/pull/11101