Skip to content

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.

  1. Ensure all desired features are merged to main branch and CHANGELOG.md is updated. Do not edit the Unreleased header in the CHANGELOG -- the next step will automatically update it.

  2. Use bump-my-version to increase the version number in all needed places, e.g. 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.

  3. Push a tag on the new commit containing the version number, prefixed with v, e.g. v1.3.0.

    git tag v1.3.0  # EXAMPLE version number

    Tip

    It's a good idea to use git log, e.g. git log --decorate --oneline --pretty to verify the tag is on the correct commit before pushing.

    git push origin v1.3.0  # EXAMPLE version number

  4. Create a new GitHub Release. 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.

  5. Once the package is visible on PyPI, check it's installable with 

    python -m pip install earthaccess==vX.Y.Z

  6. 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.