Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update releasing docs from run-through with Nikki #834

Merged
merged 5 commits into from
Oct 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 52 additions & 16 deletions docs/contributing/releasing.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,26 +3,62 @@
> :memo: The versioning scheme we use is [SemVer](http://semver.org/). 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.
1. Ensure all desired features are merged to `main` branch and `CHANGELOG.md` is
nikki-t marked this conversation as resolved.
Show resolved Hide resolved
updated. **Do not** edit the `Unreleased` header in the CHANGELOG -- the next step
will automatically update it.

1. Use `bump-my-version` to increase the version number in all needed places, e.g. to
nikki-t marked this conversation as resolved.
Show resolved Hide resolved
increase the minor version (`1.2.3` to `1.3.0`):

```plain
bump-my-version bump minor
```
```plain
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`.

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

```plain
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.

```plain
git push origin v1.3.0 # EXAMPLE version number
```

1. [Create a new GitHub Release](https://github.com/nsidc/earthaccess/releases/new). We
hand-curate our release notes to be valuable to humans. Please do not auto-generate
release notes and aim for consistency with the GitHub Release descriptions from other
releases.

> :gear: After the GitHub release is published, multiple automations will trigger:
>
> - Zenodo will create a new DOI.
> - GitHub Actions will publish a PyPI release.

> :memo: `earthaccess` is published to conda-forge through the
> [earthdata-feedstock](https://github.com/conda-forge/earthdata-feedstock), as this
> project was renamed early in its life. The conda package is named `earthaccess`.
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.

1. Once the package is visible on PyPI, check it's installable with `pip install
earthaccess==vX.Y.Z`.

1. After the package is released on PyPI, follow the
[conda-forge maintainer process](https://conda-forge.org/docs/maintainer/) to release
the package on conda-forge.

!!! note

:memo: `earthaccess` is published to conda-forge through the
[earthdata-feedstock](https://github.com/conda-forge/earthdata-feedstock), as
this project was renamed early in its life. The conda package is named
`earthaccess`.
Loading