Release process

Info

The versioning scheme we use is SemVer. Note that until we agree we're ready for v1.0.0, we will not increment the major version.

Ensure all desired features are merged to main branch and CHANGELOG.md is updated. Do not edit the Unreleased header in the CHANGELOG -- that will be handled automatically in a later step.
Create a new branch to make release changes. We do not permit pushing to main and this will give the community visibility into release management activities.
Use bump-my-version to automatically increase the version number in all needed places, for example to increase the minor version (1.2.3 to 1.3.0):
```
bump-my-version bump minor
```
Add, commit, and push the files changed by bump-my-version.

Note

The files managed by bump-my-version are configured in pyproject.toml.
Open a pull request with the changes. Review, and merge.
Create a new GitHub Release. In the "Choose a tag" dialog, enter a new tag prefixed with v, for example v1.3.0.

We hand-curate our release notes to be valuable to humans. Please auto-generate release notes, but replace the "What's changed" section with the Markdown from the new CHANGELOG section for this release. Retain the "New contributors" and "Full changelog" text generated by GitHub. Ensure "Set as latest release" is checked.
Info

After the GitHub release is published, multiple automations will trigger:
- Zenodo will create a new DOI.
- GitHub Actions will publish a PyPI release.
Once the package is visible on PyPI, check it's installable with
```
python -m pip install earthaccess==vX.Y.Z
```
After the package is released on PyPI, follow the conda-forge maintainer process to release the package on conda-forge.

Note

earthaccess is published to conda-forge through the earthdata-feedstock, as this project was renamed early in its life. The conda package is named earthaccess.