Skip to content

Commit 8774c98

Browse files
committed
docs: add releasing notes
1 parent 6145c8b commit 8774c98

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

RELEASING.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# Releasing
2+
3+
This is a checklist to use when releasing a new PySTAC version.
4+
5+
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.
6+
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`).
7+
3. Update the `__version__` attribute in `pystac/version.py` with the new version.
8+
4. Update the CHANGELOG.
9+
- Create a new header below `## [Unreleased]` with the new version.
10+
- Remove any unused header sections.
11+
- Update the links at the bottom of the page for the new header.
12+
- Audit the CHANGELOG for correctness and readability.
13+
5. Audit the changes.
14+
Use the CHANGELOG, your favorite diff tool, and the merged Github pull requests to ensure that:
15+
- All notable changes are captured in the CHANGELOG.
16+
- 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.
17+
- All deprecated items that were marked for removal in this version are removed.
18+
6. Craft draft release notes (<https://github.com/stac-utils/pystac/releases/new>).
19+
These should be short, readable, and call out any significant changes, especially changes in default behavior or significant new features.
20+
These should also include a link back to the Github milestone for this release, if there is one.
21+
These should _not_ be a complete listing of changes -- those will be auto-generated later, after the tag is pushed.
22+
7. Commit your changes, push your branch to Github, and request a review.
23+
8. Once approved, merge the PR.
24+
9. Once the PR is merged, create a tag with the version name, e.g. `vX.Y.Z`.
25+
Prefer a signed tag, if possible.
26+
Push the tag to Github to trigger the PyPI publish.
27+
10. Use the tag to finish your release notes, and publish those.
28+
The "auto generate" feature is your friend, here.
29+
11. Announced the release in [Gitter](https://matrix.to/#/#SpatioTemporal-Asset-Catalog_python:gitter.im) and on any relevant social media.

0 commit comments

Comments
 (0)