Small updates to clarify change destinations

[emmyoop]

resolves #4652

Description

Since changie new is run on the main branch (where changes are made) there needs to be a way to separate what we backport and what is slated for the next major/minor release.

I came up with the following solutions.

1. Always have a folder called backport where backported changes go. The problem with this is when we backport the change, the yaml file will end up in a backport folder on the .latest branch. Not as clean as I would like.
2. Delete the yaml file off main after you backport. Really don't like this one as it requires a separate commit after all your changes are done.
3. Always have a folder for the next major/minor version, .changes/next. If something is to be backported to any .latest branch, leave the yaml file in the default folder (.changes/unreleased). If it's to be slated for the next major/minor version that we have not cut a ./latest branch for yet, the yaml file will live in this new folder. When it's time to cut the new branch, delete all yaml files under /unreleased that have been backported and generate the batch off the .changes/next folder. This could be automated along with the batch/merge automation in [CT-289] Automate Changelog Generation on Release #4789.

I went with 3 but am happy to hear feedback.

Still need to
[ ] add logic to GHA to check if /unreleased or /next contains a new file
[ ] see if this is something that could be native to changie

Edit: Solution is to change where changelog entries land based on what version they're applying to. No separate folders needed.

This PR is still needed to clean up what a release will look like for 1.1.0 since it's going to take some manual work to combine the original changelog with the new changie entries.

Checklist

• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have added information about my change to be included in the CHANGELOG.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[leahwicz]

With this solution, do you need to know you are going to backport your PR while your PR is open or can you make that decision after the PR is merged?

[emmyoop]

@leahwicz ideally you would know before it's merged. But if you change your mind it would require a new PR to move the file from one directory to another.

This doesn't create any more overhead than we have now since if you put your CHANGELOG entry (pre-changie process) into 1.1.0 but then realized you should backport it for 1.0.4, you need to manually update the CHANGELOG to reflect that. Instead of updating the CHANGELOG now, you slide the yaml file around. The benefit being no merge conflicts.

Since we need to keep backport and next changes separate, there's no way around this.

[nathaniel-may]

@emmyoop and I just had a quick sync. The key question here is about what we want our changelogs to look like post 1.0. The simplest solution for engineering would be the following:

• only one directory for new changelog entries
• when commits are backported, they include the changelog entry and can be done entirely automatically because they live in the same directory on the target branch.
• this necessarily means that a change that goes into 1.1.0 and is backported onto 1.0.4 will show up in both changelogs with identical entries which is a deviation from how we have historically done our changelog.

If this is an acceptable outcome, I'm going to advocate for this solution instead of the two directory solution.

CC: @jtcohen6

[emmyoop]

• this necessarily means that a change that goes into 1.1.0 and is backported onto 1.0.4 will show up in both changelogs with identical entries which is a deviation from how we have historically done our changelog.

Just to clarify this a touch more. The identical changelog entry will end up under the 1.0.4 heading in the 1.0.latest changelog and under the 1.1.0 heading in the 1.1.latest changelog.

This also sounds like a better/cleaner solution to me if having the entries under different headings is acceptable.

[jtcohen6]

This approach makes sense to me. I'm happy to have the same changelog entry show up in both versions. Given the nature of backporting, we are actually making the change twice. We should also expect the scope of the fix may actually be different, for minor vs. patch releases, in which case we might also edit the changie entry while backporting.