Possible upgrades to the release infrastructure

[Saransh-cpp]

• [ ] Add a note for trial run, remove the moving tag point
• [ ] Rename the release branch so that it is not confused with the tags
• [ ] Probably automate more of this (rc0 + final release can be automated more?)

cc: @kratman @agriyakhetarpal @arjxn-py

[valentinsulzer]

My understanding was that having a separate release branch allows us to keep working on develop between release candidates, and also cherry pick and release critical patches if required without having to wait until the next release

[agriyakhetarpal]

My understanding was that having a separate release branch allows us to keep working on develop between release candidates, and also cherry pick and release critical patches if required without having to wait until the next release

Makes sense, Saransh had the same thoughts as well – removed off the list

[agriyakhetarpal]

Would it be better if we were to ask maintainers to submit PRs that don't target the develop branch after a release candidate has been published? For example, this would unblock big changes like #4205 because critical patches would target the release branch instead

[kratman]

Would it be better if we were to ask maintainers to submit PRs that don't target the develop branch after a release candidate has been published? For example, this would unblock big changes like #4205 because critical patches would target the release branch instead

I think this was the idea of not using a release branch. The only thing going to main was the release, so PRs could be made there with the cherry picks for the RCs. It makes tagging easier and simplifies the workflow to only use main. Changes on main don't impact develop so it does not block PRs.

We really don't have a solution for things like #4205 being blocked while we are cherry picking changes for releases. The solution is really to speed up the release process into a single day instead of doing multiple RCs over a months time. Cherry picking releases is only easy when PRs are squashed and the changes only touch a couple files

[kratman]

Other improvements:

• [ ] The release workflows only work if the release is done in the month intended. For example if you do the may release (v24.5) in July, then the workflows try to create a release for July (e.g. v24.7rcX)
• [ ] Release/pre-release PRs should probably only be merged into main. Then a separate PR should be made to sync main with develop. This keeps release branches from being modified when the merge is performed on develop. Since the "Require branches to be up-to-date" setting forces merges all of develop into the release branch before it is merged into develop
• [ ] If we are going to merge release branches into develop, then process should probably make a different branch for each RC. This prevents contaminated branches from being used to create releases.

[Saransh-cpp]

Since the "Require branches to be up-to-date" setting forces merges all of develop into the release branch before it is merged into develop

We should really not have this as a forced thing.

Not merging the development branch into the release branch is a very standard practice (and the only practice I have seen). Copying my comment here -

The idea of the release branch is to keep the code frozen till the final release is made. The release is only made once the tests pass on the frozen branch and if the tests are failing, then the fixes are cherry-picked instead of merging develop to update the branch. Involving multiple branches will complicate the process imo, making it much more confusing. In any case, develop should never be merged in the release branches, that is the standard practice for rc releases and even backporting fixes to a stable LTS version (if pybamm had one).

Also, backport branches are always kept frozen without updates from the development branch. Only required fixes are moved to this branch.