[CT-495] Changie and Cutting a Branch

[emmyoop]

When we first cut the .latest branch when we're ready to release the rc1 for a major/minor release, we need to do some cleanup of the files in the /.changes directory.

When we cut the .latest branch, all yaml files in the /unreleased directory as well as any other version directories (ex: for the 1.1.0 release there is a /1.1.0 directory in addition to the /unreleased directory) need to be moved to the .latest branch and deleted from main.

This is also when we should update the footer to point to the 1.1 version.

I need to think this through a bit more but wanted to start an issue so it doesn't get lost. There may be a way to do it automatically.

[emmyoop]

Part of this should also be cleaning up the current state of main since there are a lot of duplicated files.

[emmyoop]

@leahwicz is there anything special about cutting the .latest branch? I'm assuming it's just a normal branch with a special name but want to make sure that's true.

To solve this (automatically) I think we'll need write an automated process. If we automated cutting the branch it could

1. Create the branch
2. Fix up the state of the changelog on main
   • delete all pending changelog yaml files
   • add the line to the footer pointing to the CHANGELOG in the new branch
   • regenerate the CHANGELOG to reflect what version main now points to and reflect the new footer
3. maybe do the version bump on main as part of the same PR?

We could also just have a process that does #2 after the branch gets cuts manually.

I'm going to fix the current state with #5109 to reduce what changelogs we need to wade through to figure out what to do and get main in a good state.

[leahwicz]

@emmyoop that is correct- we just cut the new branch from main with the certain naming convention. Nothing else. I would wait to get too much into the automation of this process since we are looking at automating this whole end to end for release so this can be a piece in the puzzle. We already need to bump the version in main after the branch is cut so maybe this can all be part of that automation step

[emmyoop]

Agreed that work shouldn't start on this yet since the release process is a WIP but wanted to document what needs to be done. That's also why I'm going to manually fix main now.

[emmyoop]

Just a thought. We cut the .latest branch when we release the first rc. This task is to clean up the changelog at that point. However, during the rc we continue to push small changes and bug fixes to .latest. Should those changelog yamls end up on the main branch or should they get cleaned up as well?

[jtcohen6]

If I'm understanding right: anything that was merged between v1.1.0-rc1 and v1.1.0 (final) will also show up in v1.2.0.

I think that's okay. As soon as we're backporting a change, it feels fair for it to show up in all the places it was merged into. In that sense, the RC → final period is almost like a patch release.

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.