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.md #4274

Merged
merged 4 commits into from
Nov 19, 2024
Merged
Changes from 1 commit
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
49 changes: 24 additions & 25 deletions RELEASING.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,9 @@
(otherwise the workflow will pick up the version from `main` and just remove the `.dev` suffix).
* Review the two pull requests that it creates.
(one is targeted to the release branch and one is targeted to `main`).
* Merge the one targeted towards the release branch.
* The builds will fail for the `main` pr because of validation rules. Follow the [release workflow](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/RELEASING.md) for the contrib repo up until this same point. Change the SHAs of each PR to point at each other to get the `main` builds to pass.
* The builds will fail for both the `main` and release pr because of validation rules. Follow the [release workflow](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/RELEASING.md) for the contrib repo up until this same point. Change the SHAs of each PR to point at each other to get the `main` and release builds to pass.
lzchen marked this conversation as resolved.
Show resolved Hide resolved
* Merge the release PR.
* Merge the PR to main (this can be done separately from [making the release](#making-the-release))

## Preparing a new patch release

Expand All @@ -33,9 +34,27 @@
* Press the "Run workflow" button, then select the release branch from the dropdown list,
e.g. `release/v1.9.x`, and click the "Run workflow" button below that.
* This workflow will publish the artifacts and publish a GitHub release with release notes based on the change log.
* Review and merge the pull request that it creates for updating the change log in main
(note that if this is not a patch release then the change log on main may already be up-to-date,
in which case no pull request will be created).
* Verify that a new [Github release](https://github.com/open-telemetry/opentelemetry-python/releases) has been created and that the CHANGELOGs look correct.

## After the release

* Check PyPI
* This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python/blob/main/.github/workflows/release.yml).
* Check the [action logs](https://github.com/open-telemetry/opentelemetry-python/actions?query=workflow%3APublish) to make sure packages have been uploaded to PyPI
* Check the release history (e.g. https://pypi.org/project/opentelemetry-api/#history) on PyPI
* If for some reason the action failed, see [Publish failed](#publish-failed) below
* Move stable tag
* Run the following (TODO automate):
```bash
git tag -d stable
git tag stable
git push --delete origin tagname
git push origin stable
```
* This will ensure that READTHEDOCs for core are pointing at the stable release.
lzchen marked this conversation as resolved.
Show resolved Hide resolved
* To validate this worked, ensure the stable build has run successfully:
https://readthedocs.org/projects/opentelemetry-python/builds/.
If the build has not run automatically, it can be manually trigger via the READTHEDOCs interface.

## Notes about version numbering for stable components

Expand Down Expand Up @@ -68,26 +87,6 @@
* The version number for unstable components in the `main` branch will be bumped to the next version,
e.g. `0.{Y+1}b0.dev`.

## After the release

* Check PyPI
* This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python/blob/main/.github/workflows/release.yml).
* Check the [action logs](https://github.com/open-telemetry/opentelemetry-python/actions?query=workflow%3APublish) to make sure packages have been uploaded to PyPI
* Check the release history (e.g. https://pypi.org/project/opentelemetry-api/#history) on PyPI
* If for some reason the action failed, see [Publish failed](#publish-failed) below
* Move stable tag
* Run the following (TODO automate):
```bash
git tag -d stable
git tag stable
git push --delete origin tagname
git push origin stable
```
* This will ensure the docs are pointing at the stable release.
* To validate this worked, ensure the stable build has run successfully:
https://readthedocs.org/projects/opentelemetry-python/builds/.
If the build has not run automatically, it can be manually trigger via the readthedocs interface.

## Releasing dev version of new packages to claim namespace

When a contribution introduces a new package, in order to mitigate name-squatting incidents, release the current development version of the new package under the `opentelemetry` user to simply claim the namespace. This should be done shortly after the PR that introduced this package has been merged into `main`.
Expand Down
Loading