| RELEASING.md (dd8ab4d9aed6d8670d11495d68e790fb4ea5ad64) | RELEASING.md (8ec64e9ae9d5df169dba8c8ee61d8ec8907b8f80) |
|---|---|
| 1# Release Procedures 2 3*These notes are meant for a maintainer to create official releases.* 4 5In preparing a release, create a branch to hold pre-release commits. 6We ideally want all release mechanics (for all languages) to be in one commit, which will then be tagged. 7(This will change if/when we stop synchronizing releases across all language bindings.) 8 9## Core C library 10 11Some minor bookkeeping updates are needed when releasing a new version of the core library. 12 13The version number must be updated in 14 15* `include/ceed/ceed.h` 16* `ceed.pc.template` 17* `Doxyfile` 18* `CITATION.cff` 19 | 1# Release Procedures 2 3*These notes are meant for a maintainer to create official releases.* 4 5In preparing a release, create a branch to hold pre-release commits. 6We ideally want all release mechanics (for all languages) to be in one commit, which will then be tagged. 7(This will change if/when we stop synchronizing releases across all language bindings.) 8 9## Core C library 10 11Some minor bookkeeping updates are needed when releasing a new version of the core library. 12 13The version number must be updated in 14 15* `include/ceed/ceed.h` 16* `ceed.pc.template` 17* `Doxyfile` 18* `CITATION.cff` 19 |
| 20Additionally, the release notes in `doc/sphinx/source/releasenotes.rst` should be updated. | 20Additionally, the release notes in `doc/sphinx/source/releasenotes.md` should be updated. |
| 21Use `git log --first-parent v0.7..` to get a sense of the pull requests that have been merged and thus might warrant emphasizing in the release notes. 22While doing this, gather a couple sentences for key features to highlight on [GitHub releases](https://github.com/CEED/libCEED/releases). 23The "Current Main" heading needs to be named for the release. 24 25Use `make doc-latexpdf` to build a PDF users manual and inspect it for missing references or formatting problems (e.g., with images that were converted to PDF). 26This contains the same content as the website, but will be archived on Zenodo. 27 28### Quality control and good citizenry 29 301. If making a minor release, check for API and ABI changes that could break [semantic versioning](https://semver.org/). 31The [ABI compliance checker](https://github.com/lvc/abi-compliance-checker) is a useful tool, as is `nm -D libceed.so` and checking for public symbols (capital letters like `T` and `D` that are not namespaced). 32 332. Double check testing on any architectures that may not be exercised in continuous integration (e.g., HPC facilities) and with users of libCEED, such as MFEM and PETSc applications. | 21Use `git log --first-parent v0.7..` to get a sense of the pull requests that have been merged and thus might warrant emphasizing in the release notes. 22While doing this, gather a couple sentences for key features to highlight on [GitHub releases](https://github.com/CEED/libCEED/releases). 23The "Current Main" heading needs to be named for the release. 24 25Use `make doc-latexpdf` to build a PDF users manual and inspect it for missing references or formatting problems (e.g., with images that were converted to PDF). 26This contains the same content as the website, but will be archived on Zenodo. 27 28### Quality control and good citizenry 29 301. If making a minor release, check for API and ABI changes that could break [semantic versioning](https://semver.org/). 31The [ABI compliance checker](https://github.com/lvc/abi-compliance-checker) is a useful tool, as is `nm -D libceed.so` and checking for public symbols (capital letters like `T` and `D` that are not namespaced). 32 332. Double check testing on any architectures that may not be exercised in continuous integration (e.g., HPC facilities) and with users of libCEED, such as MFEM and PETSc applications. |
| 34While unsupported changes do not prevent release, it's polite to make a PR to support the new release, and it's good for quality to test before taggin a libCEED release. | 34While unsupported changes do not prevent release, it's polite to make a PR to support the new release, and it's good for quality to test before tagging a libCEED release. |
| 35 363. Update and test all the language bindings (see below) within the branch. 37 384. Check that `spack install libceed@develop` works prior to tagging. 39The Spack `libceed/package.py` file should be updated immediately after tagging a release. 40 41### Tagging and releasing on GitHub 42 --- 127 unchanged lines hidden (view full) --- 170rust/libceed-sys/build.rs: .atleast_version("0.8") 171rust/libceed/Cargo.toml:version = "0.8.0" 172rust/libceed/Cargo.toml:libceed-sys = { version = "0.8", path = "../libceed-sys" } 173rust/libceed/README.md:libceed = "0.8.0" 174``` 175 176After doing this, 177 | 35 363. Update and test all the language bindings (see below) within the branch. 37 384. Check that `spack install libceed@develop` works prior to tagging. 39The Spack `libceed/package.py` file should be updated immediately after tagging a release. 40 41### Tagging and releasing on GitHub 42 --- 127 unchanged lines hidden (view full) --- 170rust/libceed-sys/build.rs: .atleast_version("0.8") 171rust/libceed/Cargo.toml:version = "0.8.0" 172rust/libceed/Cargo.toml:libceed-sys = { version = "0.8", path = "../libceed-sys" } 173rust/libceed/README.md:libceed = "0.8.0" 174``` 175 176After doing this, 177 |
| 1781. `cargo package --list` to see that the file list makes sense. 1792. `cargo package` to build crates locally 1803. `cargo publish` to publish the crates to https://crates.io | 1781. `cargo package --list --package libceed-sys` and `--package libceed` to see that the file list makes sense. 1792. `cargo release` to build crates locally (handling dependencies between creates in the workspace) 1803. `cargo release publish --execute` to publish the crates to https://crates.io |