diff --git a/distribution/README.md b/distribution/README.md index f0ca205f37d..66d74f805fb 100644 --- a/distribution/README.md +++ b/distribution/README.md @@ -1,81 +1,43 @@ # Distributing MODFLOW 6 -This folder contains scripts to automate MODFLOW 6 distribution tasks. +This document describes release procedures for MODFLOW 6. This folder contains scripts to automate MODFLOW 6 distribution tasks. - - [Overview](#overview) - [Requirements](#requirements) +- [Steps](#steps) + - [Update release notes](#update-release-notes) + - [Update version info](#update-version-info) + - [Build makefiles](#build-makefiles) + - [Build example models](#build-example-models) + - [Benchmark example models](#benchmark-example-models) + - [Build documentation](#build-documentation) + - [Build the distribution archive](#build-the-distribution-archive) + - [Verify the distribution archive](#verify-the-distribution-archive) +- [Procedure](#procedure) - [Testing](#testing) -- [Release procedures](#release-procedures) - - [Preparing a minimal development release](#preparing-a-minimal-development-release) - - [Preparing an official release](#preparing-an-official-release) - - [Updating version info](#updating-version-info) - - [Building makefiles](#building-makefiles) - - [Building example models](#building-example-models) - - [Benchmarking example models](#benchmarking-example-models) - - [Building documentation](#building-documentation) - - [Building the distribution archive](#building-the-distribution-archive) - - [Verifying the distribution archive](#verifying-the-distribution-archive) -- [Release automation](#release-automation) - - [Nightly builds](#nightly-builds) - - [Official releases](#official-releases) - - [Triggering with a release branch](#triggering-with-a-release-branch) - - [Triggering a release manually](#triggering-a-release-manually) - - [Release versioning](#release-versioning) + - [Testing release scripts](#testing-release-scripts) + - [Testing the release workflow](#testing-the-release-workflow) ## Overview -This document describes release procedures for MODFLOW 6. Manually preparing a release involves running scripts in the `distribution` directory in a particular order: - -1. Update version info: `update_version.py` -2. Run benchmarks: `benchmark.py` -3. Build documentation: `build_docs.py` -4. Build distribution: `build_dist.py` - -This process is automated in the `.github/workflows/release.yml` workflow. - -The `build_dist.py` script is lazy — benchmarks, example models and documentation artifacts are downloaded via the GitHub API if available, and only re-created if none exist or the `--force` (`-f`) flag is provided. This allows the release workflow to consume artifacts previously created by other workflow runs, reducing the time needed to create and publish a release. - -## Requirements - -This document assumes a MODFLOW 6 development environment has been configured as per the [developer documentation](../DEVELOPER.md), including a Fortran compiler (either `ifort` or `gfortran`) as well as a Conda environment as specified in `environment.yml`. Official distributions are currently prepared with Intel Fortran (`ifort`). - -## Testing - -Each script in `distribution/` contains its own tests. To run them, run `pytest` from the `distribution/` folder. The tests will not be discovered if `pytest` is run from a different location, as the scripts in this folder are not named `test_*.py` and are only discoverable by virtue of the patterns provided in `distribution/pytest.ini`. The tests use temporary directories where possible and revert modifications to tracked files on teardown. - -**Note:** the tests clean up by reverting changes to files in the following locations: - -- `doc/` -- `make` -- `utils/**/make/` - -Make sure you don't have any uncommitted changes in these locations before running the tests. - -**Note:** to avoid contested file access, the tests **should not be run in parallel** with `pytest-xdist`. - -There is a small additional suite of tests that can be used to validate a release distribution folder after it is built: `check_dist.py`. These tests are run as part of the release workflow. - -## Release procedures - -MODFLOW 6 release come in two flavors: +MODFLOW 6 releases come in two flavors: - nightly development builds - full/approved distributions -Development builds are created nightly from the tip of the `develop` branch and released from the [`MODFLOW-USGS/modflow6-nightly-build` repository](https://github.com/MODFLOW-USGS/modflow6-nightly-build). Development distributions contain only MODFLOW 6 input/output documentation and core executables and libraries: +Development builds are created nightly from the tip of the `develop` branch and released from the [`MODFLOW-USGS/modflow6-nightly-build` repository](https://github.com/MODFLOW-USGS/modflow6-nightly-build). Development distributions contain only MODFLOW 6 input/output documentation, release notes, `code.json` metadata, and core executables and libraries: - `mf6`: MODFLOW 6 executable - `zbud6`: Zonebudget executable - `mf5to6`: MODFLOW 5 to 6 converter executable - `libmf6`: MODFLOW 6 dynamic library -Full distributions, on the other hand, contain the items listed above, as well as: +Full distributions contain the items listed above, as well as: - Meson build files - Fortran source code @@ -90,32 +52,49 @@ Full distributions, on the other hand, contain the items listed above, as well a - docs for various MODFLOW 6 features and packages - docs for `mf5to6` and `zbud6` +Official releases can be classified further into two types: patch and minor releases. Patch releases should typically branch from `master` and cherry-pick relevant commits, since `develop` may contain broader changes not yet ready for release. Minor releases typically branch from `develop`. MODFLOW 6 does not currently increment the major version number. -### Preparing a minimal development release +Both nightly builds and official distributions are created automatically with GitHub Actions. -Development releases are built and [posted nightly on the `MODFLOW-USGS/modflow6-nightly-build` repository](https://github.com/MODFLOW-USGS/modflow6-nightly-build/releases). For a minimal release, distribution contents include: +## Requirements -- platform-specific distributions containing only executables `mf6`, `zbud6`, `mf5to6` and library `libmf6` -- MODFLOW 6 input/output documentation -- release notes -- `code.json` metadata +This document assumes a MODFLOW 6 development environment has been configured as per the [developer documentation](../DEVELOPER.md), including a Fortran compiler (either `ifort` or `gfortran`) as well as a Conda environment as specified in `environment.yml`. Official distributions are currently prepared with Intel Fortran (`ifort`). -The `build_dist.py` script can be used to create both minimal and full distributions. By default, a minimal distribution is created. To create a full distribution, run the script with the `--full` flag: +## Steps -The script has several other arguments: +Broadly, steps to prepare an official release for distribution include: -- `--build-path`: path to the build workspace, defaults to `/builddir` -- `--output-path (-o)`: path to create a distribution zipfile, defaults to `/distribution/` -- `--examples-repo-path (-e)`: path to the [`MODFLOW-USGS/modflow6-examples`](https://github.com/MODFLOW-USGS/modflow6-examples) repository, defaults to `modflow6-examples` side-by-side with project root -- `--force (-f)`: whether to recreate and overwrite preexisting components of the distribution, if they already exist +- update release notes for the release (and reset them after) +- update version information with `update_version.py` +- (re)build makefiles with `build_makefiles.py` +- benchmark example models with `benchmark.py` +- build the MF6IO documentation with `build_docs.py` +- build the distribution archive with `build_dist.py` +- verify the distribution archive with `check_dist.py` + +These should occur roughly in the order presented above. The procedure is automated in the `.github/workflows/release.yml` and `release_dispatch.yml` workflows. + +**Note**: `git`- and/or GitHub-related steps are omitted from this section. See the [Procedure](#procedure) section below for a step-by-step recipe for creating and distributing release with the help of GitHub Actions. + +### Update release notes + +The release notes document is constructed from the `doc/ReleaseNotes/ReleaseNotes.tex` LaTeX file. During each development cycle, release notes should be maintained in `doc/ReleaseNotes/develop.tex` — this file is referenced from `doc/ReleaseNotes/ReleaseNotes.tex`. + +Before making a release, add a line to the Release History section of `ReleaseNotes.tex` providing the version number, date and DOI of the current release, e.g. `6.4.4 & February 13, 2024 & \url{https://doi.org/10.5066/P9FL1JCC}`. -Default paths are resolved relative to the script's location on the filesystem, *not* the current working directory, so the script can be run from `distribution/`, from the project root, or from anywhere else. (This is true of all scripts in the `distribution/` directory.) +After each release is made, several steps are required to reset the release notes for the next development cycle: -### Preparing an official release +- copy `develop.tex` into a new file `doc/ReleaseNotes/previous/vx.y.z.tex` (where `x.y.z` is the semantic version just released) +- add a new entry like `\input{./previous/vx.y.z.tex}` to line 3 of `doc/ReleaseNotes/appendixA.tex` +- overwrite `develop.tex` with the contents of `doc/ReleaseNotes/vx.y.z-template.tex` -To prepare an official release for distribution, the steps are as follows: +Now new changes can be added to `develop.tex` as development proceeds. -#### Updating version info +**Note**: Newly deprecated MF6IO options are included in the release notes. See the [developer docs](../DEVELOPER.md#deprecation-policy) for more info on MF6's deprecation policy, searching for deprecations among DFNs, and generating a deprecations table for insertion into the release notes. + +### Update version info + +MODFLOW 6 version numbers follow the [semantic versioning](https://semver.org/) convention `major.minor.patch`. Release tags do *not* include an initial `v`, as is common in many other projects. Version information is stored primarily in `version.txt` in the project root, as well as in several other files in the repository. @@ -137,11 +116,17 @@ python update_version.py -v 6.4.2rc The label must start immediately following the patch version number, with no space in between. The label may contain numeric characters or symbols, but *must not* start with a number (otherwise there is no way to distinguish it from the patch version number). -The `--approved` (short `-a`) flag can be used to approve an official release. If the `--approved` flag is provided, disclaimer language is altered to reflect approval. If the flag is not provided, the language reflects preliminary/provisional status and `(preliminary)` is appended to version numbers. +The `update_version.py` script has a few other flags: + +- `--approved` (short `-a`): approve an official release. If the `--approved` flag is provided, disclaimer language is altered to reflect approval. If the flag is not provided, the language reflects preliminary/provisional status and `(preliminary)` is appended to version numbers. + +- `--releasemode` (short `-r`): toggle whether binaries are built in development or release mode by editing the contents of `src/Utilities/version.f90`. If the `--releasemode` flag is provided, `IDEVELOPMODE` is set to 0. If `--releasemode` is not provided, `IDEVELOPMODE` is set to 1. -The `--releasemode` flag can be used to control whether binaries are built in development or release mode by editing the contents of `src/Utilities/version.f90`. If the `--releasemode` flag is provided, `IDEVELOPMODE` is set to 0. If `--releasemode` is not provided, `IDEVELOPMODE` is set to 1. +- `--get` (short `-g`): print the current version number to `stdout` without making any updates. -#### Building makefiles +- `--citation` (short `-c`): generate a citation from the contents of `CITATION.cff` and print it to `stdout`, again without making any updates. + +### Build makefiles The `build_makefiles.py` script is used to rewrite makefiles after Fortran source files have been added, removed, or renamed. Up-to-date makefiles must be generated for inclusion in a distribution. To build makefiles, run: @@ -149,11 +134,11 @@ The `build_makefiles.py` script is used to rewrite makefiles after Fortran sourc python build_makefiles.py ``` -#### Building example models +### Build example models MODFLOW 6 [example models](https://github.com/MODFLOW-USGS/modflow6-examples) are bundled with official releases. Example models must be built and run to generate plots and tables before documentation can be generated. The `release.yml` workflow attempts to download the latest release from the examples repository, only re-building and re-running example models if no such release is available. See the examples repository for more information on preparing example models. -#### Benchmarking example models +### Benchmark example models MODFLOW 6 documentation includes a performance evaluation comparing the current version against the last official release. Benchmarks must run before a release can be prepared. Benchmarks run as a component of the `docs.yml` CI workflow — `release.yml` attempts to download benchmark results if available, only re-running them if necessary. @@ -172,68 +157,89 @@ python benchmark.py -e ../modflow6-examples -o .benchmarks The above will write results to a markdown file `.benchmarks/run-time-comparison.md` relative to the project root. -#### Building documentation +### Build documentation -Extensive documentation is bundled with official MODFLOW 6 releases. MODFLOW 6 documentation is written in LaTeX. Some LaTeX files (in particular for MODFLOW 6 input/output documentation) is automatically generated from DFN files. The `release.yml` workflow first runs `update_version.py` to update version strings to be substituted into the docs, then runs `build_docs.py` to regenerate LaTeX files where necessary, download benchmark results (and convert the Markdown results file to LaTeX), download publications hosted on the USGS website, and finally convert LaTeX to PDFs. +Extensive documentation is bundled with official MODFLOW 6 releases. MODFLOW 6 documentation is written in LaTeX. Some LaTeX files (in particular for MODFLOW 6 input/output documentation) are automatically generated from DFN files. The `release.yml` workflow first runs `update_version.py` to update version strings to be substituted into the docs, then runs `build_docs.py` to regenerate LaTeX files where necessary, download benchmark results (and convert the Markdown results file to LaTeX), download publications hosted on the USGS website, and finally convert LaTeX to PDFs. Manually building MODFLOW 6 documentation requires additional Python dependencies specified in `build_rtd_docs/requirements.rtd.txt`. Styles defined in the [`MODFLOW-USGS/usgslatex`](https://github.com/MODFLOW-USGS/usgslatex) are also required. (See that repository's `README` for installation instructions or this repo's [`../.github/workflows/docs.yml](../.github/workflows/docs.yml) CI workflow for an example.) -#### Building the distribution archive +### Build the distribution archive -After each step above is complete, the `build_dist.py` script can be used to construct the MODFLOW 6 distribution. See [the `release.yml` workflow](../.github/workflows/release.yml) for a complete example of how to build a distribution archive. +After each step above is complete, the `build_dist.py` script can be used to construct the MODFLOW 6 distribution. The `build_dist.py` script can be used to create both minimal and full distributions. By default, a minimal distribution is created. To create a full distribution, run the script with the `--full` flag. -#### Verifying the distribution archive +The `build_dist.py` script is lazy — benchmarks, example models and documentation artifacts are downloaded via the GitHub API if available, and only re-created if none exist or the `--force` (`-f`) flag is provided. This allows the release workflow to consume artifacts previously created by other workflow runs, reducing the time needed to create and publish a release. -The `check_dist.py` script can be used to check the release distribution folder. The `--path` argument is the path to the dist folder. The `--approved` flag can be used to signal that the release is approved/official. By default the release is assumed preliminary. The script checks the version string emitted by `mf6 -v` for the presence or absence of "preliminary" depending on this flag. +The script has several other arguments: -## Release automation +- `--build-path`: path to the build workspace, defaults to `/builddir` +- `--output-path (-o)`: path to create a distribution zipfile, defaults to `/distribution/` +- `--examples-repo-path (-e)`: path to the [`MODFLOW-USGS/modflow6-examples`](https://github.com/MODFLOW-USGS/modflow6-examples) repository, defaults to `modflow6-examples` side-by-side with project root +- `--force (-f)`: whether to recreate and overwrite preexisting components of the distribution, if they already exist -Both nightly builds and official distributions are built automatically with GitHub Actions. +Default paths are resolved relative to the script's location on the filesystem, *not* the current working directory, so the script can be run from `distribution/`, from the project root, or from anywhere else. This is true of all scripts in the `distribution/` directory. -### Nightly builds +See [the `release.yml` workflow](../.github/workflows/release.yml) for a complete example of how to build a distribution archive. -As mentioned, development releases are automatically built and posted nightly on the [`MODFLOW-USGS/modflow6-nightly-build`](https://github.com/MODFLOW-USGS/modflow6-nightly-build) repository. +### Verify the distribution archive + +The `check_dist.py` script can be used to check the release distribution folder. The `--path` argument is the path to the dist folder. The `--approved` flag can be used to signal that the release is approved/official. By default the release is assumed preliminary. The script checks the version string emitted by `mf6 -v` for the presence or absence of "preliminary" depending on this flag. -### Official releases +## Procedure -The procedure above to prepare an official release is reproduced in `.github/workflows/release.yml`. This workflow has no triggers of its own, and must be dispatched by `.github/workflows/release_dispatch.yml`. A release can be dispatched in two ways: +The steps above are automated in the `.github/workflows/release.yml` and `release_dispatch.yml` workflows. The `.github/workflows/release.yml` workflow is used for both nightly builds and official releases. It should not be necessary to prepare a release manually. -- Push a release branch to the `MODFLOW-USGS/modflow6` repository. -- Manually trigger the workflow via GitHub CLI or web UI. +The `release.yml` workflow has no triggers of its own, and must be dispatched by `.github/workflows/release_dispatch.yml`, in one of two ways: -#### Triggering with a release branch +- Push a release branch to the `MODFLOW-USGS/modflow6` repository. This method should be used for proper releases. +- Manually trigger the workflow via GitHub CLI or web UI. Useful for testing release candidates or verifying the release automation before a final release is made — see the [Testing](#testing) section below for more detail. -To release a new version of MODFLOW 6: +To release an official version of MODFLOW 6 via the release branch method: 1. Create a release candidate branch from the tip of `develop` or `master`. The branch's name must begin with `v` followed by the version number. For an officially approved release, include *only* the version number. For a preliminary release candidate, append `rc` after the version number, e.g. `v6.4.0rc`. If the branch name does not end in `rc`, the release is assumed to be approved. 2. Push the branch to the `MODFLOW-USGS/modflow6` repository. This triggers the release workflow. If the release is still an unapproved candidate (i.e. the branch name ends with `rc`) binaries are built with `IDEVELOPMODE` set to 1, and the workflow ends after uploading binaries and documentation artifacts for inspection. If the release is approved/official, the workflow drafts a pull request against the `master` branch. -3. To continue with the release, merge the PR into `master`. This triggers another job to tag the new tip of `master` with the release number, draft a release post, upload binaries and documentation as release assets, and create another PR updating the `develop` branch from `master`, resetting version files, and setting `IDEVELOPMODE` back to 1. -4. To finalize the release, publish the release post and merge the PR into `develop`. +3. To continue with the release, merge (**do not squash**) the PR into `master`. This triggers another job to tag the new tip of `master` with the release number, draft a release, and upload binaries and documentation as release assets. +4. If the release assets pass inspection, publish the release. The following format convention is used for the GitHub release post: -#### Triggering a release manually + ``` + This is the approved USGS MODFLOW release. + + , , MODFLOW 6 Modular Hydrologic Model version : U.S. Geological Survey Software Release, , + + Visit the USGS "MODFLOW and Related Programs" site for information on MODFLOW 6 and related software: https://doi.org/10.5066/F76Q1VQV + ``` -The `workflow_dispatch` event is GitHub's mechanism for manually triggering workflows. This can be accomplished from the Actions tab in the GitHub UI. +5. Create a branch from `master`, naming it something like `post-release-x.y.z-reset`. Run `distribution/update_version.py -v x.y.z.devN`, substituting `x`, `y`, `z` and `N` as appropriate for the next development cycle's version number. This will substitute the version number into all necessary files and will also set `IDEVELOPMODE` back to 1. Reset release notes as described [above](#update-release-notes). Open a pull request into `master` from the reset branch. Merge (**do not squash**) the PR. -Navigate to the Actions tab of this repository. Select the release dispatch workflow. A `Run workflow` button should be visible in an alert at the top of the list of workflow runs. Click the `Run workflow` button, selecting values for the various inputs: +**Note**: Squashing the release PR into `master` or the post-release reset PR into `develop` causes `develop` and `master` to diverge, leading to conflicts at the next release time. Both pull requests should be **merged with a merge commit**, *not* squashed. -- `approve`: whether the release is officially approved, or just a release candidate -- `branch`: the branch to release from -- `development`: whether to build a minimal development distribution or a full distribution -- `run_tests`: whether to run autotests after building binaries -- `version`: the version number of the release +## Testing -### Release versioning +Each script used in the release procedure can be tested separately. The procedure can also be tested end-to-end by manually dispatching the release workflow. -MODFLOW 6 version numbers follow the [semantic versioning](https://semver.org/) convention `major.minor.patch`. Release tags do *not* include an initial `v`, as is common in many other projects. +### Testing release scripts -Patch releases should typically branch from `master`, since `develop` may contain broader changes not yet ready for release. Minor releases typically branch from `develop`. MODFLOW 6 release procedures do not currently increment the major version number. +Each script in `distribution/` contains its own tests. To run them, run `pytest` from the `distribution/` folder. The tests will not be discovered if `pytest` is run from a different location, as the scripts in this folder are not named `test_*.py` and are only discoverable by virtue of the patterns provided in `distribution/pytest.ini`. The tests use temporary directories where possible and revert modifications to tracked files on teardown. -Release notes use the following format convention: +**Note:** the tests clean up by reverting changes to files in the following locations: -``` -This is the approved USGS MODFLOW release. +- `doc/` +- `make` +- `utils/**/make/` + +Make sure you don't have any uncommitted changes in these locations before running the tests. + +**Note:** to avoid contested file access, the tests will refuse to run in parallel with `pytest-xdist`. + +There is a small additional suite of tests that can be used to validate a release distribution folder after it is built: `check_dist.py`. These tests are run as part of the release workflow — see below for more detail. + +### Testing the release workflow + +The `workflow_dispatch` event is GitHub's mechanism for manually triggering workflows. This can be accomplished from the Actions tab in the GitHub UI. This is a convenient way to test the release procedure and evaluate release candidate distributions. -, , MODFLOW 6 Modular Hydrologic Model version : U.S. Geological Survey Software Release, , +To dispatch the release workflow, navigate to the Actions tab of this repository. Select the release dispatch workflow. A `Run workflow` button should be visible in an alert at the top of the list of workflow runs. Click the `Run workflow` button, selecting values for the various inputs: -Visit the USGS "MODFLOW and Related Programs" site for information on MODFLOW 6 and related software: https://doi.org/10.5066/F76Q1VQV -``` \ No newline at end of file +- `approve`: whether the release is officially approved, or just a release candidate +- `branch`: the branch to release from +- `development`: whether to build a minimal development distribution or a full distribution +- `run_tests`: whether to run autotests after building binaries +- `version`: the version number of the release \ No newline at end of file diff --git a/distribution/benchmark.py b/distribution/benchmark.py index b92d533fec3..4c56ce49481 100644 --- a/distribution/benchmark.py +++ b/distribution/benchmark.py @@ -27,7 +27,11 @@ _is_windows = sys.platform.lower() == "win32" _app_ext = ".exe" if _is_windows else "" _soext = ".dll" if _is_windows else ".so" -_ostag = "win64" if _is_windows else "linux" if sys.platform.lower().startswith("linux") else "mac" +_ostag = ( + "win64" + if _is_windows + else "linux" if sys.platform.lower().startswith("linux") else "mac" +) def download_previous_version(output_path: PathLike) -> Tuple[str, Path]: diff --git a/distribution/build_dist.py b/distribution/build_dist.py index 4d8efdfc8f6..3014ebbc381 100644 --- a/distribution/build_dist.py +++ b/distribution/build_dist.py @@ -103,39 +103,6 @@ def test_copy_sources(tmp_path): assert (tmp_path / "utils" / "mf5to6" / "pymake").is_dir() assert (tmp_path / "utils" / "zonebudget" / "pymake").is_dir() assert not (tmp_path / "utils" / "idmloader").is_dir() - - - -def build_examples(examples_repo_path: PathLike, overwrite: bool = False): - examples_repo_path = Path(examples_repo_path).expanduser().absolute() - - # create examples, but don't run them - examples_path = examples_repo_path / "examples" - examples_path.mkdir(parents=True, exist_ok=True) - if not overwrite and any(get_model_paths(examples_path)): - print(f"Examples already built") - else: - print(f"Building examples") - scripts_folder = examples_repo_path / "scripts" - exclude_list = ["ex-gwf-capture.py"] - scripts = [ - fname - for fname in scripts_folder.glob("*") - if fname.suffix == ".py" - and fname.stem.startswith("ex-") - and fname.stem not in exclude_list - ] - for script in scripts: - argv = [ - sys.executable, - script, - "--no_run", - "--no_plot", - "--destination", - examples_path, - ] - print(f"running {argv} in {scripts_folder}") - run_command(argv, scripts_folder) def setup_examples( diff --git a/distribution/build_docs.py b/distribution/build_docs.py index 3c74f642f13..0135753816c 100644 --- a/distribution/build_docs.py +++ b/distribution/build_docs.py @@ -117,7 +117,9 @@ def download_benchmarks( reverse=True, ) artifacts = [ - a for a in artifacts if a["workflow_run"]["head_branch"] == "develop" # todo make configurable + a + for a in artifacts + if a["workflow_run"]["head_branch"] == "develop" # todo make configurable ] most_recent = next(iter(artifacts), None) print(f"Found most recent benchmarks (artifact {most_recent['id']})") @@ -158,7 +160,9 @@ def build_benchmark_tex( # download benchmark artifacts if any exist on GitHub if not benchmarks_path.is_file(): - benchmarks_path = download_benchmarks(_benchmarks_dir_path, repo_owner=repo_owner) + benchmarks_path = download_benchmarks( + _benchmarks_dir_path, repo_owner=repo_owner + ) # run benchmarks again if no benchmarks found on GitHub or overwrite requested if overwrite or not benchmarks_path.is_file(): @@ -179,7 +183,7 @@ def build_benchmark_tex( ) assert not ret, out + err assert tex_path.is_file() - + if (_distribution_path / f"{benchmarks_path.stem}.md").is_file(): assert (_docs_path / "ReleaseNotes" / f"{benchmarks_path.stem}.tex").is_file() @@ -209,7 +213,7 @@ def build_deprecations_tex(): ) assert not ret, out + err assert tex_path.is_file() - + assert (_docs_path / "ReleaseNotes" / f"{deprecations_path.stem}.tex").is_file() @@ -489,7 +493,9 @@ def build_documentation( if not full: # convert LaTeX to PDF - build_pdfs_from_tex(tex_paths=_dev_dist_tex_paths, output_path=output_path, overwrite=overwrite) + build_pdfs_from_tex( + tex_paths=_dev_dist_tex_paths, output_path=output_path, overwrite=overwrite + ) else: # convert benchmarks to LaTex, running them first if necessary build_benchmark_tex( diff --git a/doc/ReleaseNotes/develop.tex b/doc/ReleaseNotes/develop.tex index 11ac03ea128..cbef622e93b 100644 --- a/doc/ReleaseNotes/develop.tex +++ b/doc/ReleaseNotes/develop.tex @@ -39,12 +39,12 @@ % \item xxx %\end{itemize} - \underline{ADVANCED STRESS PACKAGES} - \begin{itemize} - \item Refactoring of the Water Mover package in version 6.4.3 introduced a reduction in performance for GWF models with a large number of movers. The program was corrected so that performance is similar to previous versions. + %\underline{ADVANCED STRESS PACKAGES} + %\begin{itemize} + % \item % \item xxx % \item xxx - \end{itemize} + %\end{itemize} %\underline{SOLUTION} %\begin{itemize} diff --git a/doc/ReleaseNotes/vx.x.x-template.tex b/doc/ReleaseNotes/vx.y.z-template.tex similarity index 100% rename from doc/ReleaseNotes/vx.x.x-template.tex rename to doc/ReleaseNotes/vx.y.z-template.tex