Determine process for fixing changelog

Summary

During the release process, the release manager checks the changelog generated by towncrier and might find issues - typos, miscategorizations, etc. See https://github.com/astropy/astropy/pull/12478 for some examples. We need to determine the optimal way of dealing with such fixes.

When the LTS release branch is the latest release branch

In the first 6 months after a new LTS release, there is only one release branch. At this point, the process is simple - any issues can be fixed directly in the generated changelog and committed to the release branch. This is because the news fragments are deleted and we then forward-port the deletion of the fragments to main so there are no more news fragments to worry about

When there are two release branches

Once a non-LTS release is done, there are now two release branches which means that some news fragments will live in both, so we need to be a little more careful. There are several options at this point:

1. Make any changes to the news fragments in main and backport to both release branches. This will require resolving conflicts when backporting to the LTS branch since some of the news fragments may not exist there.
2. Make any changes to the news fragments in the release branch, and forward-port that to main then backport to the other release branch. Then if the current active release being done is non-LTS, we have to then also forward-port the deletion of the news fragments to main in a separate PR. This is messy because it means several different backports/forward-ports and is just really confusing 🤯
3. Make any changes to the news fragments in the release branch, then ‘side’-port that commit to the other release branch. The idea here is that the news fragments are going to get deleted anyway in main so why bother going via main when really the fixes just need to be in the release branches. This does still require potential conflict resolution when side-porting because not all news fragments will exist in the other release branch.
4. Follow the same process as when the LTS release is the only release branch, and just make the same changes - manually - in the LTS branch if needed (or if doing the LTS release before the other release, also do the changes manually in the other release branch)

One thing to consider is that once there are two release branches, the number of changes/bug fixes is going to slowly decrease in the LTS branch. In fact out of all the changes for the 5.0 release there were only 6 changes/fixes suggested by @eteq so it might be that no or only a couple of fixes are required to be made in the LTS branch at each release after 6 months. So it may be worth not over-engineering this and seeing if Option 4 is good enough. The other options require manual conflict resolution anyway so it might not be much work to do Option 4? If we want to not do it completely manually, then I would advocate Option 3 because it does not delay the release being done, whereas Option 1 does. Option 2 is just… no.

If issues are caught between releases

If people notice issues with the generated changelog at https://docs.astropy.org/en/latest/changelog.html#changelog and it’s not release time, I think the correct process is to fix the fragments in main and mark the PR doing this as needing backporting to the relevant branches.

We have until the 5.1 release to figure this out 😄

[eteq]

@pllim : :trollface:

[pllim]

Is this still relevant?