When you implement some sort of feature in GHC, we want to communicate that in several places. If you add a new function that should have a `@since` pragma. If you add a new language extension, that should have a user guide page with information about when it was introduced. And we also want to add one or more changelog entries. Right now all of this requires manual work to add. This is made more complicated by our usage of multiple release branches. For instance, a new contributor making a change to `base` might struggle to know what version to put into the `@since` pragma or changelog entry for their new function. Time can also pass between when they make their MR and when it gets merged, and that might have an impact on the target version too. ## Proposal I think we could have a much nicer workflow by automating these things. What `cabal-install` does seems nice to me. They have a changelog.d directory and you create a new file when you add a feature. They then use https://codeberg.org/fgaz/changelog-d to turn these into a changelog when making a release. Using a directory like this makes cherry-picking much easier, since you don't get conflicts from adjacent entries in a file, and you don't have to update versions when backporting. For dealing with `@since` pragmas, I think the easiest thing is to use a placeholder like `NEXT_GHC_VERSION` and then grep for these when making a release. This means that contributors do not need to know which release their feature will land in, and it means that if a feature is backported you won't accidentally have a future version of GHC as your since version. Perhaps we want to do something more complicated when features like flags get backported, and say what the earliest minor versions are where it is available for each major version. That could be handled by having a placeholder for each feature, like `BETTER_FOO_VERSIONS`, and then a script could check which versions of GHC have that changelog entry in its changelog directory and fill it in appropriately. These are just some rough thoughts about potential things we could do here. I don't know if it's worth putting the effort into automating something like this or if it should work exactly like this.