Making an MPAS release (Integrators only)

These instructions are for the steps integrators need to perform to make an MPAS release.

MPAS has two kinds of releases:

• major releases (e.g. v6.0)
• minor releases (e.g. v6.1) Historically it is customary to give all cores 4 weeks notice for a major release and 1 week notice for a minor release. All cores should agree on a release schedule.

Instructions assume a remote to the https://github.com/MPAS-Dev/MPAS-Model repo called MPAS-Dev/MPAS-Model.

Creating a release branch

1. Make the release branch from the correct place.
   • For a major release, the release branch should be branched off of develop. Ensure develop contains the state of the code intended for release. Merge CORE/develop branches to develop as needed and push develop to MPAS-Dev/MPAS-Model.
   • For a minor release, the release branch should be made off of the tag of its parent major release. Bug fixes or required features should be branched off of the parent major release tag (or something older) and merged directly into the release branch. Those branches can also be merged into develop if they are needed immediately.
2. Create a release branch locally, e.g.: git checkout -b release-v6.1 MPAS-Dev/MPAS-Model/develop
3. Update the MPAS version number in Registry.xml in each core. There is a script in the MPAS-Tools repo that does this automatically, but at present it does not work correctly. However, it is easy enough to do by hand. An easy way to find all the files that need to be changed is git grep version=. Ignore results defining the XML defintion like <?xml version="1.0"?>; only worry about results like <registry model="mpas" core="atmosphere" core_abbrev="atm" version="6.0">. Edit each Registry.xml file so that the version is updated to the release version. Also update the version number in the README.md file in the root directory. Commit these changes as the first commit on the release branch.
4. Push release branch to MPAS-Dev/MPAS-Model.
5. Wait the agreed upon time for all core maintainers to perform testing and any needed minor cleanup on the release branch. For a major release this will be a few weeks, but for a minor release it can be shorter.
6. During this period, core maintainers can merge pull requests to the release branch with minor fixes/updates.

Creating the release

Once the allotted wait time is complete, the release can be finalized.

1. ...