Fix semver workflow to conform to regex conventions in GitHub (#1573)

### What kind of change does this PR introduce?

* Bug fix to deal with how regex is handled in GitHub Workflows

### Does this PR introduce a breaking change?

No.

### Other information:

Worth noting: https://github.com/mpalmer/action-validator

.github/workflows/bump-version.yml

@@ -6,19 +6,18 @@ on:
       - master
     paths-ignore:
       - .*
-      - .github/**.yml
+      - .github/*/*.yml
       - CHANGES.rst
       - Makefile
-      - docs/**.ipynb
-      - docs/**.py
-      - docs/**.rst
+      - docs/*/*.ipynb
+      - docs/*/*.py
+      - docs/*/*.rst
       - docs/Makefile
       - docs/make.bat
       - docs/references.bib
       - environment.yml
       - pylintrc
       - pyproject.toml
-      - requirements_dev.txt
       - requirements_upstream.txt
       - tox.ini
       - xclim/__init__.py
@@ -53,20 +52,19 @@ jobs:
       - name: Install bump-my-version
         run: |
           python -m pip install bump-my-version
-      - name: Bump Patch Version
-        if: ${{ !env.CURRENT_VERSION =~ \d+\.\d+\.\d+(-dev(\.\d+)?)?$ }}
+      - name: Conditional Bump
+        id: bump
         run: |
-          echo "Version is stable, bumping 'patch' version"
-          bump-my-version bump patch
-          NEW_VERSION="$(grep -E '__version__'  xclim/__init__.py | cut -d ' ' -f3)"
-          echo "new_version=${NEW_VERSION}"
-      - name: Bump Build Version
-        if: ${{ env.CURRENT_VERSION =~ \d+\.\d+\.\d+(-dev(\.\d+)?)?$ }}
-        run: |
-          echo "Development version (ends in 'dev(\.\d+)?'), bumping 'build' version"
-          bump-my-version bump build
+          if [[ $CURRENT_VERSION =~ \d+\.\d+\.\d+-dev(\.\d+)?$ ]]; then
+            echo "Development version (ends in 'dev(\.\d+)?'), bumping 'build' version"
+            bump-my-version bump build
+          else
+            echo "Version is stable, bumping 'patch' version"
+            bump-my-version bump patch
+          fi
           NEW_VERSION="$(grep -E '__version__'  xclim/__init__.py | cut -d ' ' -f3)"
           echo "new_version=${NEW_VERSION}"
+          echo "NEW_VERSION=${NEW_VERSION}" >> $GITHUB_ENV
       - name: Push Changes
         uses: ad-m/[email protected]
         with:

CHANGES.rst

@@ -30,6 +30,7 @@ Internal changes
 * The `flake8` configuration has been migrated from `setup.cfg` to `.flake8`; `setup.cfg` has been removed. (:pull:`1569`)
 * The `bump-version.yml` workflow has been adjusted to bump the `patch` version when the last version is determined to have been a `release` version; otherwise, the `build` version is bumped. (:issue:`1557`, :pull:`1569`).
 * The GitHub Workflows now use the `step-security/harden-runner` action to monitor source code, actions, and dependency safety. All workflows now employ more constrained permissions rule sets to prevent security issues. (:pull:`1577`).
+* Updated the CONTRIBUTING.rst directions to showcase the new versioning system. (:issue:`1557`, :pull:`1573`).
 
 v0.47.0 (2023-12-01)
 --------------------

CONTRIBUTING.rst

@@ -354,47 +354,41 @@ The method we use is as follows::
 
 **Patch** should be used for bug fixes and optimizations;
 
-**Release** is a keyword used to specify the degree of production readiness (`beta` [, and optionally, `gamma`]). *Only versions built from the main development branch will ever have this tag!*
+**Release** is a keyword used to specify the degree of production readiness (`dev` [, and optionally, `release`]). *Only versions built from the main development branch will ever have this marker!*
 
-  An increment to the Major or Minor will reset the Release to `beta`. When a build is promoted above `beta` (ie: release-ready), it's a good idea to push this version towards PyPi.
+**Build** is a keyword used to specify the build number. *Only versions built from the main development branch will ever have this number!*
 
-Deploying
----------
+An increment to the Major or Minor will reset the Release to `beta`. When a build is promoted above `beta` (ie: the release/stable version), it's a good idea to push this version towards PyPI.
 
-A reminder for the maintainers on how to prepare the library for a tagged version.
+Packaging and Deployment
+------------------------
 
-Make sure all your changes are committed (**including an entry in HISTORY.rst**).
-Then run::
+This section serves as a reminder for the maintainers on how to prepare the library for a tagged version and how to deploy packages to TestPyPI and PyPI.
 
-    $ bump2version <option>  # possible options: major / minor / patch / release
+When a new version has been minted (features have been successfully integrated test coverage and stability is adequate), maintainers should update the pip-installable package (wheel and source release) on PyPI as well as the binary on conda-forge.
+
+From a new branch (e.g. `prepare-v123`), open a Pull Request and make sure all your changes to support a new version are committed (**update the entry for newest version in CHANGES.rst**), Then run::
+
+    $ bump-my-version bump <option>  # possible options: major / minor / patch / release / build
 
 These commands will increment the version and create a commit with an autogenerated message.
 
-For PyPI releases/stable versions, ensure that the last version bumping command run is `$ bump2version release` to remove the `-dev`.
-These changes can now be merged to the main development branch::
+For PyPI releases/stable versions, ensure that the last version bumping command run is `$ bump-my-version bump release` to remove the `-dev`. These changes can now be merged to the `prepare-v123` branch::
 
-    $ git push
+    $ git push origin prepare-v123
 
-With this performed, we can tag a version that will act as the GitHub-provided stable source archive.
-Be sure to only tag from the `main` branch when all changes from PRs have been merged! Commands needed are::
+With this performed, we can tag a version that will act as the GitHub-provided stable source archive. **Be sure to only tag from the `main` branch when all changes from PRs have been merged!** The commands needed are::
 
-    $ git tag v1.2.3-XYZ
+    $ git tag v1.2.3
     $ git push --tags
 
 .. note::
-    Starting from October, 2021, all tags pushed to GitHub will trigger a build and publish a package to TestPyPI by default. TestPyPI is a testing ground that is not indexed or easily available to `pip`.
-    The test package can be found at `xclim on TestPyPI`_.
-
-Packaging
----------
-
-When a new version has been minted (features have been successfully integrated test coverage and stability is adequate),
-maintainers should update the pip-installable package (wheel and source release) on PyPI as well as the binary on conda-forge.
+    Starting from October, 2021, all tags pushed to GitHub will trigger a build and publish a package to TestPyPI by default. TestPyPI is a testing ground that is not indexed or easily available to `pip`. The test package can be found at `xclim on TestPyPI`_.
 
 The Automated Approach
 ~~~~~~~~~~~~~~~~~~~~~~
 
-The simplest way to package `xclim` is to "publish" a version on GitHuh. GitHub CI Actions are presently configured to build the library and publish the packages on PyPI automatically.
+The simplest way to package `xclim` is to "publish" a version on GitHub. GitHub CI Actions are presently configured to build the library and publish the packages on PyPI automatically.
 
 When publishing on GitHub, maintainers will need to generate the release notes for the current version, replacing the ``:issue:``, ``:pull:``, and ``:user:`` tags. The `xclim` CLI offers a helper function for performing this action::
 

pyproject.toml

@@ -122,10 +122,11 @@ target-version = [
 ]
 
 [tool.bumpversion]
-current_version = "0.47.4-beta"
+current_version = "0.47.4-dev.0"
 commit = true
+commit_args = "--no-verify"
 tag = false
-allow_dirty = true
+allow_dirty = false
 parse = "(?P<major>\\d+)\\.(?P<minor>\\d+)\\.(?P<patch>\\d+)(\\-(?P<release>[a-z]+)(\\.(?P<build>\\d+)))?"
 serialize = [
   "{major}.{minor}.{patch}-{release}.{build}",

tests/conftest.py

@@ -27,7 +27,10 @@
 from xclim.testing.utils import get_file
 from xclim.testing.utils import open_dataset as _open_dataset
 
-if not __xclim_version__.endswith("-beta") and helpers.TESTDATA_BRANCH == "main":
+if (
+    re.match(r"^\d+\.\d+\.\d+$", __xclim_version__)
+    and helpers.TESTDATA_BRANCH == "main"
+):
     # This does not need to be emitted on GitHub Workflows and ReadTheDocs
     if not os.getenv("CI") and not os.getenv("READTHEDOCS"):
         warnings.warn(

tests/test_formatting.py

@@ -53,7 +53,7 @@ def func(da, arg1, arg2=None, arg3=None):
     out = func(atmosds.tas, 1, arg2=[1, 2], arg3=None)
 
     matches = re.match(
-        r"\[([0-9-:\s]*)\]\s(\w*):\s(\w*)\((.*)\)\s-\sxclim\sversion:\s(\d*\.\d*\.\d*[a-zA-Z-]*)",
+        r"\[([0-9-:\s]*)]\s(\w*):\s(\w*)\((.*)\)\s-\sxclim\sversion:\s(\d*\.\d*\.\d*[a-zA-Z-]*(\.\d*)?)",
         out.attrs["history"],
     ).groups()
 

xclim/__init__.py

@@ -15,7 +15,7 @@
 
 __author__ = """Travis Logan"""
 __email__ = "[email protected]"
-__version__ = "0.47.4-beta"
+__version__ = "0.47.4-dev.0"
 
 
 _module_data = _files("xclim.data")