2.3. METplus Development Release

Create a new vX.Y.Z-betaN or vX.Y.Z-rcN development release from the develop branch while working toward an official vX.Y.Z release.

2.3.1. Open Release Issue

Define a new issue in the METplus repository to create the new release.
- “Create the METplus vX.Y.Z release” for an official or bugfix release.
- “Create the METplus vX.Y.Z-betaN (or -rcN) release” for a development release.
For an official or development release, assign the issue to the corresponding METplus development project.
For a bugfix release, assign the issue to the organization level support project.
Select the target milestone.

2.3.2. Clone the Project Repository

Create and work in a new directory to ensure a fresh environment:

mkdir release-X.Y.Z
cd release-X.Y.Z

Run the clone command to obtain the repository.

Using SSH:

git clone git@github.com:dtcenter/METplus

Using HTTP:

git clone https://github.com/dtcenter/METplus

Enter the project repository directory:

cd METplus

2.3.3. Checkout the Source Branch

If creating a beta (betaN) or first release candidate (rc1) release, checkout the develop branch:

git checkout develop

OR

If creating a later release candidate (rc2+) release, checkout the appropriate main branch:

git checkout main_vX.Y

2.3.4. Create Release Feature Branch

Create a feature branch in which to update the version number and add release notes being sure to include the GitHub issue number for the new release.

git checkout -b feature_NNNN_vX.Y.Z       # for an official or bugfix release
git checkout -b feature_NNNN_vX.Y.Z-betaN # for a development release
git checkout -b feature_NNNN_vX.Y.Z-rcN   # for a development release

2.3.5. Update Version Number for Release

2.3.6. Update Release Notes

You can refer to the GitHub Project board to see what has changed for this release. Open the following URL in a browser:

https://github.com/orgs/dtcenter/projects

Click on the project that corresponds to this release, i.e. METplus-X.Y.Z Development
Navigate to the “Closed Issues” tab. If this tab does not exist, see GitHub Projects to Manage Development to create it.
Update the release-notes.rst file found in the User’s Guide directory.
Consider organizing release notes into logical groups (e.g. Enhancements, Bugfixes, Documentation, etc.) and modifying GitHub issue titles for consistency. The release notes should match the GitHub issue titles, when possible.
Use your best judgement to apply bold formatting for any major or important changes.
If you are creating a beta1 release, remove the previous version’s release notes, i.e. for 3.0.0-beta1, remove all 2.Y.Z notes and start a 3.0.0 section with the format “Version X.Y.Z release notes (YYYYMMDD)”.
If you are creating a betaX release, add a new betaX section above the betaX-1 release.
Commit changes and push to GitHub.

2.3.7. Update Upgrade Instructions

Occasionally, changes will be made to software that will require users to make changes to their configuration files in order to use the latest release. For example, when ensemble post-processing was added to Gen-Ens-Prod and removed from Ensemble-Stat, users were required to make changes in their configuration files.

Note

This section is not always applicable.

To alert the users to the necessary steps involved with the upgrade:

Update the Upgrade Instructions section of the release-notes.rst file found in the METplus User’s Guide directory with the necessary information.
Add an “upgrade instructions” link next to the appropriate METplus component (METplus) after “latest” and before “development” in the METplus Components Release Note Links section in the release-notes.rst file in the METplus User’s Guide in the METplus GitHub repository ONLY if there are Upgrade Instructions for this release.

2.3.8. Update Development Timeline

For the METplus repository, update the development timeline under the METplus Release Information section.
- If you are creating an official release, edit the actual release date for the release and remove development timeline information for all beta/rc versions.
- If you are creating a beta1 release, add development timeline information with approximate dates for planned development cycles.
- For other development release, edit the actual release dates and planned release dates for future development cycles, as needed.
Commit changes and push to GitHub.

2.3.9. Update DockerHub Info in Existing Builds

In docs/Users_Guide/existing_builds.rst, update the information under the DockerHub dropdown menu.
- Review the version numbers for the MET, METplus, and METplus Analysis DockerHub items and update them as needed.
- Update the “Last Updated:” information to include the release date, e.g. November 14, 2024.
- If you are creating a beta1 release, remove the text that says “- Coming Soon!” in the dropdown menu label.
Commit changes and push to GitHub.

2.3.10. Merge Release Issue

After updating the release-specific content on a release feature branch, submit a pull request to merge those changes back into the source branch.

2.3.11. Create Release Reference Branch

Note

These instructions only apply when creating the first release candidate (rc1) development release. Skip this section for earlier beta (betaN) or later release candidate (rc2+) development releases.

For METplus, the corresponding MET release must be created before starting this step. Specifically, a DockerHub tag on dtcenter/met that is named (X+6).Y-latest must already exist. For example, for METplus 4.1.0, the MET DockerHub tag for 10.1-latest must be built. See https://hub.docker.com/repository/docker/dtcenter/met/general for a list of existing tags.
Create a branch from the develop branch for the reference branch for the new official release and push it to GitHub. The branch name should match the format main_vX.Y-ref where X.Y is the major/minor release number.

cd METplus
git checkout develop
git pull
git checkout -b main_vX.Y-ref

2.3.11.1. Update the version number

Update the content that should go into the release version but remain unchanged in the develop branch.

Note that this step is mandatory because pushing a new main_vX.Y-ref branch without any new commits will not trigger the GitHub Actions workflow to create the output Docker data volumes.

Remove -dev from the -rc1 version number:

As of METplus 4.0.0, we are naming releases with X.Y.Z format even if Z is 0.
As of METplus v4.0.0, the file containing the version number is located at metplus/VERSION.
The version should match the upcoming release with the -rc1 suffix, like X.Y.Z-rc1
Remove -dev from the version number so that it matches the release you are creating.

Commit these changes.

2.3.11.2. Push Reference Branch to GitHub

git push -u origin main_vX.Y-ref

Pushing this branch to GitHub should trigger the GitHub Actions automation that runs all of the use cases and creates Docker data volumes with the output data. These data will be used to verify that any bugfixes applied to the main_vX.Y branch does not break any of existing logic.

2.3.11.3. Monitor GitHub Actions Workflow

Navigate to https://github.com/dtcenter/METplus/actions and verify that a Testing workflow was triggered on the main_vX.Y-ref branch.

../_images/metplus-automation-reference-data.png

Wait until the entire workflow has run successfully. The final job entitled “Create Output Docker Data Volumes” should create Docker data volumes for each use case category on DockerHub (dtcenter/metplus-data-dev). The names of these volumes start with output-.

2.3.11.4. Create main branch and push to GitHub

After the truth data volumes have been generated, create the ‘main_vX.Y’ branch from ‘main_vX.Y-ref’ branch. All remaining development for the upcoming official release occurs on this new ‘main_vX.Y’ branch.

git checkout -b main_vX.Y
git push -u origin main_vX.Y

2.3.12. Create Release on GitHub

Ensure that any and all dependent releases for METplus have been created according to Release Dependencies.
Go to Releases on GitHub and click ‘Draft a new release’
For ‘Choose a tag’, create a new tag based on the version, starting with ‘v’ (i.e. vX.Y.Z-betaN, vX.Y.Z-rcN, or vX.Y.Z)
Define the ‘Target’ branch as:
- ‘develop’ for a beta development release
- ‘main_vX.Y’ for a release candidate, bugfix, or official release
Define the ‘Release title’ based on the repository name and version, without a leading ‘v’ (i.e. METplus-X.Y.Z-betaN, METplus-X.Y.Z-rcN, or METplus-X.Y.Z)
Add a link to the release notes from the METplus User’s Guide, i.e. https://METplus.readthedocs.io/en/vX.Y.Z-betaN/Users_Guide/release-notes.html (Note: the URL will not be active until the release is created) Refer to a previous release to easily copy and modify this information.
Add links to the HTML and PDF versions of the METplus User’s Guide on ReadTheDocs. https://METplus.readthedocs.io/_/downloads/en/vX.Y.Z-betaN/pdf/ (Note: the URL will not be active until the release is created) Refer to a previous release to easily copy and modify this information.

Add link to METplus_Data and add a note to instruct users to use sub-directory corresponding to this release, i.e. v4.0) Refer to a previous release to easily copy and modify this information.
If this is a development release, check the box that says “This is a pre-release” and uncheck “Set as latest release”.
Click on “Publish release”.

2.3.13. Update Version on Develop Branch

Switch to the develop branch and change metplus/VERSION value to the next release after this one with -dev added to the end. Releases will loosely following these names, but are subject to change:

Release Version	New Develop Version
X.Y.Z-beta1	X.Y.Z-beta2-dev
X.Y.Z-beta2	X.Y.Z-beta3-dev
X.Y.Z-beta3	X.Y.Z-rc1-dev
X.Y.Z-rc1	(X+1).0.0-beta1-dev OR X.(Y+1).0-beta1-dev

2.3.14. Update DTC Website

METplus software releases are announced on the DTC website. Add or update information about software releases on the website.

Instructions

Navigate to https://dtcenter.org and sign in to the Drupal interface.
Navigate to the downloads page for the METplus repository at https://dtcenter.org/community-code/metplus/download
Click on the Edit button to edit the Downloads page.
Create a new Software Release for the newly released version by clicking on Add New Release.
- For Full Title of Release type “METplus Version X.Y.Z”.
- For Related Community Code select both the “METplus” and the “METplus Wrappers” options (For Macs, hold the Command key to select both).
- For Version Label type “METplus X.Y.Z-betaN”.
- Select the Release Type (“Recommended” for official or bugfix releases or “Development” for development versions).
- Enter the Release Date.
- Click on Add Code Download then click Add Link to add links for each of the following:
  - Add Link: The URL should be the release page that was just created under the GitHub Releases tab and the link text should be the name of the release (i.e. METplus X.Y.Z-betaN).
  - Add Link: Link text should be “User’s Guide” and the URL should be the top level directory of the User’s Guide hosted on the web. Beta releases can use “develop” in the URL, but for official releases, please ensure the link uses the branch name (e.g. main_vX.Y) as opposed to the tag name (e.g. vX.Y.Z). For example, use “https://metplus.readthedocs.io/en/main_vX.Y/Users_Guide/” and NOT “https://metplus.readthedocs.io/en/vX.Y.Z/Users_Guide/”
  - Add Link: Link text should be “Existing Builds and Docker” and the URL should be the latest Existing Builds page. Beta releases can use “develop” in the URL, but for rcN and official releases, please ensure the link uses the branch name (e.g. main_vX.Y). For example, use https://metplus.readthedocs.io/en/main_vX.Y/Users_Guide/release-notes.html#existing-builds
- In the Release Notes text box provide a direct link to the release-notes.html file in the User’s Guide.
- Click on Create Release.
- Update the existing releases, as needed.
  - For a development release, ensure the “Release Type” is set to Development and change any previous Development versions to Other.
  - For a bugfix or official release, change any previous Recommended versions to Other.
  - For an official release, remove the corresponding development releases.
- Edit the “Coordinated METplus Version X.Y” software release.
  - For a bugfix release, update the existing link and text in the “Coordinated METplus-X.Y” release section with the X.Y.Z+1 information.
- Make any other necessary website updates. For example, adding the User’s Guide to https://dtcenter.org/community-code/metplus/documentation
- Click on Save at the bottom of the page.

2.3.15. Finalize Release on GitHub

Return to GitHub to finalize the details of this release.

2.3.16. Release Acceptance Testing

A single Release Acceptance Testing discussion in the METplus repository summarizes the external testing for all development cycles of the METplus components included in a coordinated release.