Per #673, finalize instructions for MET bugfix release.

docs/Release_Guide/met.rst

@@ -7,25 +7,21 @@ MET Release
 Official release (e.g. vX.Y)
 ============================
 
-.. include:: release_steps/clone_project_repository.rst
-.. include:: release_steps/checkout_develop_branch.rst
-.. include:: release_steps/review_release_notes.rst
-
 Bugfix release (e.g. vX.Y.Z)
 ============================
 
+.. include:: release_steps/open_release_issue.rst
 .. include:: release_steps/clone_project_repository.rst
 .. include:: release_steps/checkout_main_branch.rst
-.. include:: release_steps/met/update_version.rst
+.. include:: release_steps/met/update_bugfix_version.rst
 .. include:: release_steps/update_release_notes.rst
-
-
+.. include:: release_steps/merge_release_issue.rst
 .. include:: release_steps/create_release_on_github.rst
-.. include:: release_steps/metplus/create_release_extra.rst
+.. include:: release_steps/met/build_release_tarfile.rst
+.. include:: release_steps/update_dtc_website.rst
+.. include:: release_steps/close_release_issue.rst
+.. include:: release_steps/met/update_docs.rst
 
 Development release (e.g. vX.Y-betaN or vX.Y-rcN)
 =================================================
 
-.. include:: release_steps/clone_project_repository.rst
-.. include:: release_steps/checkout_develop_branch.rst
-.. include:: release_steps/review_release_notes.rst

docs/Release_Guide/release_steps/close_release_issue.rst

@@ -0,0 +1,8 @@
+Close Release Issue
+-------------------
+
+- Close the GitHub issue for creating this release.
+- If necessary, create a new milestone for the next release (e.g. next vX.Y.Z (bugfix) release).
+- If necessary, reassign any existing issues from the current to the next release.
+- Edit the milestone for the current release by updating the *Due date* with the current date.
+- Close the current milestone.

docs/Release_Guide/release_steps/merge_release_issue.rst

@@ -0,0 +1,4 @@
+Merge Release Issue
+-------------------
+
+After updating the version number and release notes on a feature branch, submit a pull request to merge those changes back into the source branch.

docs/Release_Guide/release_steps/met/build_release_tarfile.rst

@@ -0,0 +1,11 @@
+Build Release Tarfile
+---------------------
+
+The MET software is distributed as a tarfile, but not the one created by GitHub. On a project machine (e.g. kiowa), clone the MET repository and run a script to build the tarfile for the newly tagged release.
+
+.. parsed-literal::
+
+    git clone https://github.com/dtcenter/MET
+    met/scripts/met_checkout_and_build.sh tag vX.Y.Z
+
+Edit the vX.Y.Z release on GitHub by uploading the resulting tar file (met-X.Y.Z.YYYYMMDD.tar.gz) as a release asset.

docs/Release_Guide/release_steps/met/update_bugfix_version.rst

@@ -0,0 +1,7 @@
+Update Bugfix Release Version Number
+------------------------------------
+
+- Create and work on a feature branch from the corresponding *main* branch (e.g. main_vX.Y) being sure to include the GitHub issue number for the new release (e.g. feature_NNNN_vX.Y.Z).
+- Update the *met_version* variable in *met/src/basic/vx_util/util_constants.h* which defines the version number written to the MET output files.
+- Update the *version*, *release_year*, and *release_date* variables in *met/docs/conf.py* which defines the version number for the documentation.
+- Do *NOT* update the version number in the configuration files, add a new table file, or add a new test header file.

docs/Release_Guide/release_steps/met/update_development_version.rst

@@ -0,0 +1,8 @@
+Update Development Release Version Number
+-----------------------------------------
+
+- Work on a feature branch from the *develop* branch being sure to include the GitHub issue number for the new release (e.g. feature_NNNN_vX.Y.Z-betaN or feature_NNNN_vX.Y-rcN).
+- Prior to creating the first development release (e.g. beta1) for a new version, the official release version number should have already been updated.
+- If the official release version has not yet been updated (e.g. beta1), follow the official release instructions to do so.
+- If the official release version has already been updated (e.g. beta2 and beyond), do the following:
+  - Update the *version*, *release_year*, and *release_date* variables in *met/docs/conf.py* which defines the version number for the documentation.

docs/Release_Guide/release_steps/met/update_docs.rst

@@ -0,0 +1,17 @@
+Update the Documentation on the Web
+-----------------------------------
+
+- Regenerate the User's Guide and push the release to the gh-pages branch.
+- For example, on kiowa:
+
+.. parsed-literal::
+
+    git clone https://github.com/dtcenter/MET
+    cd MET/met/docs
+    git checkout vX.Y.Z
+    bash
+    conda deactivate
+    conda activate /home/met_test/.conda/envs/sphinx_env
+    make html
+
+- Store resulting html output files in the correct sub-directory on the gh-pages branch.

docs/Release_Guide/release_steps/met/update_official_version.rst

@@ -0,0 +1,13 @@
+Update Official Release Version Number
+--------------------------------------
+
+- Create and work on a feature branch from the *develop* branch being sure to include the GitHub issue number for the new release (e.g. feature_NNNN_vX.Y).
+- Update the *met_version* variable in *met/src/basic/vx_util/util_constants.h* which defines the version number written to the MET output files.
+- Update the *version*, *release_year*, and *release_date* variables in *met/docs/conf.py* which defines the version number for the documentation.
+- Update the version number in the locations listed above.
+- Update the version number listed in the MET configuration files:
+  - Default configuration files in *met/data/config*.
+  - Sample configuration files in *met/scripts/config*.
+  - Test configuration files, searching recursively, in *test/config*.
+- Add a new *met/data/table_files/met_header_columns_VX.Y.txt* defining the columns names for this version.
+- Add a new *test/hdr/met_X_Y.hdr* file defining the column names for this version for the test scripts.

docs/Release_Guide/release_steps/open_release_issue.rst

@@ -0,0 +1,4 @@
+Open Release Issue
+------------------
+
+Define a new issue in |projectRepo| repository to create the new release.

docs/Release_Guide/release_steps/update_dtc_website.rst

@@ -0,0 +1,9 @@
+Update DTC Website
+------------------
+
+- Navigate to the downloads page for the |projectRepo| repository at www.dtcenter.org.
+- Sign in to the Drupal interface and edit the Downloads page.
+- Create a new *Software Release* for the newly released version.
+    - Select the release type (*Recommended* for official or bugfix releases or *Development* for development versions). If necessary, change previously *Recommended* versions to *Other*.
+    - Add links for release tar file, *User's Guide*, *Existing Builds and Docker*, and *Release Notes* section provide a direct link to the release-notes.html in the User's Guide.
+    - If creating a new official release, be sure to add a new *Existing Builds and Docker* page.