Lines Matching refs:release

5 In preparing a release, create a branch to hold pre-release commits.
6 We ideally want all release mechanics (for all languages) to be in one commit, which will then be t…
20 Additionally, the release notes in `doc/sphinx/source/releasenotes.md` should be updated.
21 …of the pull requests that have been merged and thus might warrant emphasizing in the release notes.
23 The "Current Main" heading needs to be named for the release.
30 1. If making a minor release, check for API and ABI changes that could break [semantic versioning](…
34 …not prevent release, it's polite to make a PR to support the new release, and it's good for qualit…
39 The Spack `libceed/package.py` file should be updated immediately after tagging a release.
46 2. `git push` updates the PR holding release; opportunity for others to review
50 6. Draft a [new release on GitHub](https://github.com/CEED/libCEED/releases), using a few sentences…
67 When there is a new release of libCEED, both of these components need to be updated.
129 ### Moving development tests to release tests
132 …ts are run both with the current build of libCEED, and with the most recent release of libCEED_jll.
133 The _development_ tests may use features which were not available in the most recent release, and s…
135 Upon release, the development tests may be moved to the release tests, so that these features will …
136 The release tests are found in the file `julia/LibCEED.jl/test/runtests.jl` and the development tes…
142 1. CI builds and tests wheels when a pull request has the `release preparation` label. One can also…
173 $ cargo release --no-tag --no-push --no-publish 0.12.0 --execute
179 2. `cargo release` to build crates locally (handling dependencies between creates in the workspace)
180 3. `cargo release publish --execute` to publish the crates to https://crates.io