Reduce release frequency

[brosaplanella]

After today's developer meeting we agreed to move to less frequent releases. The plan is to move to 3 releases a year (Jan, May, Sep) keeping calendar versioning (i.e. 23.1, 23.5 and 23.9). The release schedule from now should be 23.4 (end Apr), 23.5 (end May) and then 23.9 (end Sep).

Tasks:

• Fix release workflow
• Announce new release schedule

[agriyakhetarpal]

That is a good idea. Glad to take it up in multiple PRs or in a single one

[brosaplanella]

Copying here the main points from the discussion we had in the infrastructure Slack channel about this topic.

• Automated publication of a release candidate into PyPI one month before the actual release (i.e. end of Dec, Apr and Aug). This should allow packages depending on PyBaMM to test and fix the new release.
• If there are issues building the wheel or issues are flagged downstream, we will make further release candidates manually.
• Once we are happy with the release candidate, we merge to main which would trigger the actual release.

[brosaplanella]

If I understood correctly, the plan is:

• Release candidate is deployed to a separate branch (we can have a release-candidate branch).
• We tag it, which triggers publishing the release candidate.
• The final release is done on main

The only thing not clear to me is how we go from release candidate to release? Do we make changes to release-candidate and then merge in to main? Or do we go develop to main directly?

[brosaplanella]

UPDATED PLAN

• Feature freeze: create branch vXX.XX at the end of the month previous to the release (e.g. Apr, Aug, Dec). Update version to XX.XXrc0 in the version file (CHANGELOG can be XX.XX).
• Build wheels and publish rc.
• If needed, fix bugs and increase rc number. We can merge vXX.XX to develop but not the other way around.
• Once we are happy with the rc, we remove the rcX tag and make the final release by merging into main.

Questions:

• How/when do we update the version number in develop?
• Which steps above do we want to automate?
  • Feature freeze branch?
  • Publish to PyPI when release is tagged? (rcs are prereleases)

Answers:

• We merge main into develop after the release to update version.
• Automated workflow that we push to PyPI when a Github release is made (convert current workflow into this).

[brosaplanella]

I was thinking about the version update of develop. I am a bit worried that merging the release branch back into develop will result into CHANGELOG conflicts to fix every time. Should we update the version to the new one (e.g. v23.9) in develop and then branch out to branch v23.9, where we set the rc0 tag manually and eventually make the release from there?

Then we can also modify the old automatic PR to trigger at the end of the previous month for the feature freeze.

[agriyakhetarpal]

A note that we have an issue open for using towncrier (#2885) which could potentially resolve the problem of CHANGELOG conflicts