Merge pull request #320 from EC-USGS/v2.0.0

Release 2.0.0

Author: jmccreight

.flake8

@@ -28,73 +28,96 @@ pushed to this repo.
 To release a new version:
 
 1. Test asv benchmarking with the `-q` flag to ensure it is working (multiple
-    platformas a bonus).
+   platformas a bonus). You can merge the ref you are testing, but you cant
+   test the release ref on main until after the release is made, so that step
+   will come below and those details will merge to develop and not the
+   release.
+
+1. If there are extended release notes to put in the gh-pages branch, once
+   you have approval, change the dates of the appropriate pages to the
+   desired release date. Change any links to the extended documentation in
+   develop branch to match. Push gh-pages branch to confirm in develop before
+   releasing.
 
 1. On your local machine, create a release branch from `develop` or a patch
    branch from `main`.  The branch's name must follow format
    `v{major}.{minor}.{patch}` ([semantic version](https://semver.org/) number
    with a leading 'v'). For instance, for a minor release, if this repo is an
    `upstream` remote and one's local `develop` is up to date with upstream
-   `develop`, then from `develop` run `git switch -c vx.y.z`.
+   `develop`, then from `develop` run `git switch -c vx.y.z`. 
 
 1. If this is a patch release, make changes/fixes locally. If this is a major or
-    minor release, no changes are needed.
-
-	In either case, add the release version and date to the top of
-    `doc/whats-new.rst`. If a patch, put it below the pending minor release.
+   minor release, no changes may be needed. In either case, add the release version
+   and date to the top of `doc/whats-new.rst`. If a patch, put it below the
+   pending minor release. Also update the version in `doc/index.rst`. Update the
+   CITATION.cff file. If a major release, get the provisional new DOI from USGS
+   and add it to CITATION.cff and the main README.md.
 
 1. Push the branch to this repo. For instance, if this repo is an `upstream`
    remote: `git push -u upstream vx.y.z`. This starts a job to:
-
     - Check out the release branch and update version number in `version.txt` and
       `pywatershed/version.py` to match the version in the branch name.
     - Build and check the Python package.
     - Upload the package as an artifact.
     - Draft a PR against `main` with the updated version files.
 
 1. On all platforms, pull the release from upstream and perform ASV performance
-	benchmarks against previous release , e.g., ```asv run --verbose
-	--show-stderr HASHFILE:pws_refs_for_asv.txt``` after editing the file to
-	contain the previous and current release. Collect performance results from
-	various machines into a single report and use `asv publish` to generate
-	the static webpages to be included with the release as artifacts in that
-	step below.
+   benchmarks against previous release , e.g., ```asv run --verbose
+   -show-stderr HASHFILE:pws_refs_for_asv.txt``` after editing the file to
+   contain the previous and current release. Collect performance results from
+   various machines into a single report and use `asv publish` to generate
+   the static webpages to be included with the release as artifacts in that
+   step below.
 
 1. Inspect the package. If it looks good, merge the PR to `main`.
 
-    **Note**: it is critical to *merge* the PR to `main`, not squash as is
-    conventional for development PRs. Squashing causes `develop` and `main` to
-    diverge. Merging to `main` preserves commit history and ensures `develop`
-    and `main` don't diverge.
+   **Note**: it is critical to *merge* the PR to `main`, not squash as is
+   conventional for development PRs. Squashing causes `develop` and `main` to
+   diverge. Merging to `main` preserves commit history and ensures `develop`
+   and `main` don't diverge.
 
-    Merging the PR to `main` will trigger another job to draft a [GitHub
-    release](https://github.com/EC-USGS/pywatershed/releases). The release is
-    not yet publicly visible at this point.
+   Merging the PR to `main` will trigger another job to draft a [GitHub
+   release](https://github.com/EC-USGS/pywatershed/releases). The release is
+   not yet publicly visible at this point.
 
 1. Inspect the GitHub release. If needed, make any manual edits to the release
    notes. If the release looks good, publish it via GitHub UI or CLI. Manually
    add the asv static web pages and frozen conda dependencies for each platform.
 
    Publishing the release on GitHub automatically tags the head of `main` with
    the release version number (**Note**: release tags, unlike branches, don't
-   include an initial `v`, as is common in some projects) and triggers jobs to:
+   include an initial `v`, as is common in some projects) and triggers jobs to
+   publish the package to PyPI.
 
-    - Publish the package to PyPI
-    - Check out `main`
-    - Run `.github/scripts/update_version.py -v x.y+1.0.dev0` to update
-      `version.txt` and `pywatershed/version.py` with the minor version number
-      incremented. The `.dev0` suffix indicates preliminary development status.
-    - Draft a PR against `develop` with the updated version files and the
-      updates previously merged to `main`.
+1. Delete the release branch on upstream.
 
-1. In the case of a minor or major release, a couple of manual steps:
-    - Update the PR against `develop` to add a new minor or major release to
-      the top of `doc/whats-new.rst`
-    - Update `main` image on WholeTale to have the current release.
+1. On all platforms, pull the release from upstream and perform ASV performance
+   benchmarks against previous release. First delete `.asv/` entirely (unless
+   there's some good reason to keep `.asv/envs`), then update
+   `pws_refs_for_asv.txt` to have the previous release and the above release,
+   next `asv run --verbose --show-stderr HASHFILE:pws_refs_for_asv.txt`. Collect
+   performance results from various machines into a single `.asv/results/`, then
+   use `asv publish` to generate the static webpages in `.asv/html`. When these
+   are to your liking, add them to the gh-pages branch in the `asv/vM-m-p`
+   directory.
+
+1. In the case of a minor or major release,  (a patch would be applied to both
+   main and develop?) a couple of manual steps:
+   - Check out `main` as a new branch to get it back into develop,
+     eg feat_main_to_dev.
+   - Run `.github/scripts/update_version.py -v x.y+1.0.dev0` to update
+     `version.txt` and `pywatershed/version.py` with the minor version number
+     incremented. The `.dev0` suffix indicates preliminary development status.
+   - Add a new minor release to the top of `doc/whats-new.rst`
+   - Incorporate the ASV details from the previous section above.
+   - Open a PR against `develop` with the updated version files and the
+     updates previously merged to `main`.
 
 1. Merge the PR to `develop`. As above, it is important to *merge* the PR, not
    squash, to preserve history and keep `develop` and `main` from diverging.
 
+1. Update `main` image on WholeTale to have the current release.
+
 
 ## Utility scripts
 

.github/RELEASE.md

@@ -29,7 +29,7 @@ def get_authors():
 
 
 def update_version_py(timestamp: datetime, version: Version):
-    lines = (
+    _ = (
         open(_version_py_path, "r").readlines()
         if _version_py_path.exists()
         else []
@@ -38,7 +38,8 @@ def update_version_py(timestamp: datetime, version: Version):
     with open(_version_py_path, "w") as f:
         f.write(
             f"# {_project_name} version file automatically created using "
-            f"{Path(__file__).name} on {timestamp:%B %d, %Y %H:%M:%S}\n\n"
+            f"{Path(__file__).name} on {timestamp:%B %d, %Y %H:%M:%S}"
+            "  #noqa: E501\n\n"
         )
         f.write(f'__version__ = "{version}"\n')
         f.writelines(
@@ -48,13 +49,13 @@ def update_version_py(timestamp: datetime, version: Version):
                 "author_dict = {\n",
             ]
             + [
-                f"    \"{a['given-names']} {a['family-names']}\": \"{a['email']}\",\n"
+                f"    \"{a['given-names']} {a['family-names']}\": \"{a['email']}\",\n"  # noqa: E501
                 for a in authors
             ]
             + [
                 "}\n",
                 '__author__ = ", ".join(author_dict.keys())\n',
-                '__author_email__ = ", ".join(s for _, s in author_dict.items())\n',
+                '__author_email__ = ", ".join(s for _, s in author_dict.items())\n',  # noqa: E501
             ]
         )
         f.close()
@@ -81,7 +82,7 @@ def update_version(
     finally:
         try:
             lock_path.unlink()
-        except:
+        except:  # noqa: E722
             pass
 
 
@@ -96,7 +97,7 @@ def update_version(
             provided, the version number will not be changed. A file lock is held
             to synchronize file access. The version tag must comply with standard
             '<major>.<minor>.<patch>' format conventions for semantic versioning.
-            """
+            """  # noqa: E501
         ),
     )
     parser.add_argument(
@@ -110,7 +111,7 @@ def update_version(
         "--get",
         required=False,
         action="store_true",
-        help="Just get the current version number, don't update anything (defaults to false)",
+        help="Just get the current version number, don't update anything (defaults to false)",  # noqa: E501
     )
     args = parser.parse_args()
 
@@ -121,7 +122,7 @@ def update_version(
     else:
         update_version(
             timestamp=datetime.now(),
-            version=Version(args.version)
-            if args.version
-            else _current_version,
+            version=(
+                Version(args.version) if args.version else _current_version
+            ),
         )