-
Notifications
You must be signed in to change notification settings - Fork 121
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
29 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
# Releasing | ||
|
||
This is a checklist to use when releasing a new PySTAC version. | ||
|
||
1. Determine the next version. We do not currently have a versioning guide, but <https://github.com/radiantearth/stac-spec/discussions/1184> has some discussion around the topic. | ||
2. Create a release branch with the name `release/vX.Y.Z`, where `X.Y.Z` is the next version (e.g. `1.7.0`). | ||
3. Update the `__version__` attribute in `pystac/version.py` with the new version. | ||
4. Update the CHANGELOG. | ||
- Create a new header below `## [Unreleased]` with the new version. | ||
- Remove any unused header sections. | ||
- Update the links at the bottom of the page for the new header. | ||
- Audit the CHANGELOG for correctness and readability. | ||
5. Audit the changes. | ||
Use the CHANGELOG, your favorite diff tool, and the merged Github pull requests to ensure that: | ||
- All notable changes are captured in the CHANGELOG. | ||
- The type of release is appropriate for the new version number, i.e. if there are breaking changes, the MAJOR version number must be increased. | ||
- All deprecated items that were marked for removal in this version are removed. | ||
6. Craft draft release notes (<https://github.com/stac-utils/pystac/releases/new>). | ||
These should be short, readable, and call out any significant changes, especially changes in default behavior or significant new features. | ||
These should also include a link back to the Github milestone for this release, if there is one. | ||
These should _not_ be a complete listing of changes -- those will be auto-generated later, after the tag is pushed. | ||
7. Commit your changes, push your branch to Github, and request a review. | ||
8. Once approved, merge the PR. | ||
9. Once the PR is merged, create a tag with the version name, e.g. `vX.Y.Z`. | ||
Prefer a signed tag, if possible. | ||
Push the tag to Github to trigger the PyPI publish. | ||
10. Use the tag to finish your release notes, and publish those. | ||
The "auto generate" feature is your friend, here. | ||
11. Announced the release in [Gitter](https://matrix.to/#/#SpatioTemporal-Asset-Catalog_python:gitter.im) and on any relevant social media. |