|
1 | 1 | # Releasing |
2 | 2 |
|
3 | | -## Checklist |
| 3 | +We use [release-please](https://github.com/googleapis/release-please) to manage versioning and creating Github releases. |
| 4 | +Look for a release [pull request](https://github.com/stac-utils/rustac/pulls) to see what's queued up. |
| 5 | +To release, simply merge that pull request, then: |
4 | 6 |
|
5 | | -1. Determine which package(s) you're releasing. |
6 | | -2. Determine the package's next version. |
7 | | - [cargo-semver-checks](https://github.com/obi1kenobi/cargo-semver-checks) and [cargo-public-api](https://crates.io/crates/cargo-public-api) are handy tools for this. |
8 | | -3. Create a release branch named `release/{package name}-{version}`, e.g. `release/stac-v1.2.3`. |
9 | | -4. Update the package's `Cargo.toml` file accordingly, and update the other packages' `Cargo.toml` if they depend on this package. |
10 | | -5. Scan the package's README for references to version numbers, and update any that are needed. |
11 | | -6. Update the package's CHANGELOG with a new section for the new version. Don't forget to update the links at the bottom, too. |
12 | | -7. If it's a breaking release, search for any deprecated functions that should be removed. |
13 | | -8. Test the release with `cargo release -p {package name}`. By default, this does a dry-run, so it won't actually do anything. |
14 | | -9. Use the normal pull request workflow to merge your branch. |
15 | | -10. Once merged, run `cargo release --execute` to do the release. Use the same `-p` flags as you did during the dry run. |
| 7 | +```sh |
| 8 | +cargo publish --workspace |
| 9 | +``` |
16 | 10 |
|
17 | | -## After-the-fact releases |
18 | | - |
19 | | -Sometimes, the **main** branch has moved on, but you realize that you want to release a version of one of the packages from some previous commit, e.g. before a breaking change. |
20 | | -Follow the above workflow, with the following changes: |
21 | | - |
22 | | -- Create your release branch from the point in history where you'd like to release from, not **main**. |
23 | | -- When your release pull request is approved, _don't_ merge it right away. Instead, run `cargo release --execute`. Then, manually merge your release branch into **main** -- you'll probably have to do some careful manual fixes to the CHANGELOGs. After you've merged, just push directly to **main**. This ensures we don't lose the tagged commit via an inadvertent Github rebase-and-merge. |
24 | | - |
25 | | -## Semantic versioning and deprecation |
26 | | - |
27 | | -All packages in **rustac** follow semantic versioning as best they can. |
28 | | -We do not currently require deprecation before removal, so features may disappear between breaking releases. |
29 | | -This may change in the future as the packages mature. |
| 11 | +You may need to `--exclude` or `--include` certain packages, depending on what's changed. |
0 commit comments