Small fix to changelog

[momchil-flex]

One item that was not yet released had made it in 2.7.1 changelog instead of in the unreleased section.

I updated this changelog to be in line with the one in the pre/2.8 branch after we just merged develop there. There's generally a bit of an issue with the changelog when we do such merges. Both branches have Unreleased section where we put new things. When we do a merge, those two get merged and the items that should go in the next patch vs. the next minor release get intertwined.

This is probably at least partly caused by this merge strategy I introduced a long time ago when the changelog was causing conflicts in almost every PR (maybe exacerbated by us using rebase rather than merge workflow).

We could try removing this and then probably manually resolving things more often, but at least will hopefully not be reaching a point where it's not clear what item came from where?

Or we could try to use a different strategy, like have avoiding putting the things under the same Unreleased header, and use the next version header instead even if unreleased? This is what I did here by explicitly introducing the 2.7.2 section.

[yaugenst-flex]

Hm seems tricky to automatically merge changelogs from those two branches as long as they both write to the same section of the changelog but have different target sections. Resolving manually seems quite ok generally?

Alternatively, we could only merge develop into pre/ after a release so that the unreleased section in develop will always be empty when merged into pre/, then (on the prerelease branch) patch releases will appear below Unreleased and Unreleased will only contain changes from pre/?
And in the (hopefully rare) occasion where we merge develop into pre/ outside of a regular release, we resort back to resolving manually?

[momchil-flex]

Hm seems tricky to automatically merge changelogs from those two branches as long as they both write to the same section of the changelog but have different target sections. Resolving manually seems quite ok generally?

Seems a bit error prone, otherwise not too painful...

Alternatively, we could only merge develop into pre/ after a release so that the unreleased section in develop will always be empty when merged into pre/, then (on the prerelease branch) patch releases will appear below Unreleased and Unreleased will only contain changes from pre/? And in the (hopefully rare) occasion where we merge develop into pre/ outside of a regular release, we resort back to resolving manually?

That's kind of what we'd been doing until now. I think there were a couple of reasons to want to merge now, the readthedocs sync action was broken on pre/2.8 and @caseyflex needs to develop a 2.8 feature on top of code that's currently in develop but not in pre/2.8.

[yaugenst-flex]

I see. I guess another alternative, similar to what you mentioned, would be to just put changes in pre/2.8 under the [2.8.0] section, since we kind of know that that's where those features will appear? This keeps the develop branch a bit more flexible. And since it's the default branch, it makes sense to keep the Unreleased section there.

[momchil-flex]

Hm yeah I like that!

[daquinteroflex]

I see. I guess another alternative, similar to what you mentioned, would be to just put changes in pre/2.8 under the [2.8.0] section, since we kind of know that that's where those features will appear? This keeps the develop branch a bit more flexible. And since it's the default branch, it makes sense to keep the Unreleased section there.

Yeah I like this approach too as it separates the relevant sections cleanly!