Feature #2754 rc1_main_vX.Y

[JohnHalleyGotway]

Note that I deleted the push_release_branch.rst instructions since it's not needed. The preceeding instructions execute the push and this is redundant - even for METplus which has custom instructions.

Pull Request Testing

• Describe testing already performed for these changes:
  
  Ran make clean html to make sure the docs build.

• Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  
  Please review updated docs for clarity and accuracy:
  https://metplus.readthedocs.io/en/feature_2754_rc1_main_vx.y/Release_Guide/index.html

• Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]

• Do these changes include sufficient testing updates? [Yes]
  None needed.

• Will this PR result in changes to the test suite? [No]
  
  If yes, describe the new output and/or changes to the existing output:
  

• Do these changes introduce new SonarQube findings? [No]
  
  If yes, please describe:

• Please complete this pull request review by [Wed 10/30/24].
  

Pull Request Checklist

See the METplus Workflow for details.

• Add any new Python packages to the METplus Components Python Requirements table.
• For any new datasets, an entry to the METplus Verification Datasets Guide.
• Review the source issue metadata (required labels, projects, and milestone).
• Complete the PR definition above.
• Ensure the PR title matches the feature or bugfix branch name.
• Define the PR metadata, as permissions allow.
  Select: Reviewer(s) and Development issue
  Select: Milestone as the version that will include these changes
  Select: Coordinated METplus-X.Y Support project for bugfix releases or METplus-Wrappers-X.Y.Z Development project for official releases
• After submitting the PR, select the ⚙️ icon in the Development section of the right hand sidebar. Search for the issue that this PR will close and select it, if it is not already selected.
• After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• Close the linked issue and delete your feature or bugfix branch from GitHub.

[georgemccabe]

I need to review this more closely, but I think the instructions get mucked up in terms of version numbers, at least for the METplus Development steps.

I think additional changes are needed to:

• In the METplus Development Update Version Number for Release step, we should not update the version number if creating an rc1 release. The version gets updated in the main_vX.Y-ref branch later and also gets updated in the develop branch later.
• In the METplus Development Create Release Reference Branch sub-step Update the version number, we may want to update the example to include an -rc1 version since this step should only be run for that version.
• In METplus Development Update Version on Develop Branch, if we just created an rc1 release, the version number in develop should reflect development towards beta1 for the next release after the one we are currently developing towards.

This may apply to other release instructions as well.

[JohnHalleyGotway]

I note that instructions reference a file named docs/version.

Checking the repos I see that:

• The METdataio version is defined in METdataio/docs/version as 3.0.0-rc1-dev.
• The METcalcpy version is defined in METcalcpy/docs/version as __version__="3.0.0-rc1-dev".
• The METplotpy version is defined in METplotpy/docs/conf.py as version = 'v3.0.0-rc1-dev'.
• The METviewer version is defined in METviewer/docs/conf.py as version = "3.0.0-rc1-dev".
• The METplus version is defined in METplus/metplus/VERSION as 6.0.0-rc1-dev.
• The MET version is defined in MET/src/basic/vx_util/util_constants.h as static const char * const met_version = met_version_12_0_0;

We have custom instructions for updating the version numbers for MET and METplus.

• The METdataio/METcalcpy instructions are correct, referring to docs/version.
• The METplotpy/METviewer instructions are INCORRECT since docs/version does not exist.

@jprestop and @bikegeek can you please review this situation and advise? Can we handle the version definition consistently across all the METplus-Analysis repositories? Or is there a good reason for them to be different?

[jprestop]

@JohnHalleyGotway I noticed these differences when I was cutting the releases and created this issue to try to make them more consistent Update release notes for METplus components #2737.

[JohnHalleyGotway]

@georgemccabe thanks for taking a look. I did just update the METplus example to switch from betaN to rc1:

-  with -dev added to the end like X.Y.Z-betaN-dev, i.e. 4.0.0-beta1-dev
+  with -dev added to the end like X.Y.Z-rc1-dev, i.e. 4.0.0-rc1-dev

However, I don't really appreciate the intricacies of when/where you want -dev to be added/removed.

Please feel free to check out this feature branch and directly modify it to update the -dev handling instructions as needed.

[georgemccabe]

I made a number of changes to:

• Properly update the version numbers
• Select the appropriate branch for releases (betaN and rc1 vs. rc2+, main for official releases)
• Update the develop branch version number after creating an rc1 release

Note there is some duplication in the component-specific instructions for update_version_on_develop.rst that could be consolidated using variables, but I did not make those changes.