|
9 | 9 | (otherwise the workflow will pick up the version from `main` and just remove the `.dev` suffix).
|
10 | 10 | * Review the two pull requests that it creates.
|
11 | 11 | (one is targeted to the release branch and one is targeted to `main`).
|
12 |
| - * Merge the one targeted towards the release branch. |
13 |
| - * 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. |
| 12 | + * 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. |
| 13 | + * Change the CONTRIB_REPO_SHA of core PRs to point to their counterpart in contrib. |
| 14 | + * Change the CORE_REPO_SHA of contrib PRs to point to their counterpart in core. |
| 15 | + * Release builds now should pass. |
| 16 | + * Merge the release PR. |
| 17 | + * Merge the PR to main (this can be done separately from [making the release](#making-the-release)) |
14 | 18 |
|
15 | 19 | ## Preparing a new patch release
|
16 | 20 |
|
|
33 | 37 | * Press the "Run workflow" button, then select the release branch from the dropdown list,
|
34 | 38 | e.g. `release/v1.9.x`, and click the "Run workflow" button below that.
|
35 | 39 | * This workflow will publish the artifacts and publish a GitHub release with release notes based on the change log.
|
36 |
| - * Review and merge the pull request that it creates for updating the change log in main |
37 |
| - (note that if this is not a patch release then the change log on main may already be up-to-date, |
38 |
| - in which case no pull request will be created). |
| 40 | + * Verify that a new [Github release](https://github.com/open-telemetry/opentelemetry-python/releases) has been created and that the CHANGELOGs look correct. |
| 41 | + |
| 42 | +## After the release |
| 43 | + |
| 44 | +* Check PyPI |
| 45 | + * This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python/blob/main/.github/workflows/release.yml). |
| 46 | + * Check the [action logs](https://github.com/open-telemetry/opentelemetry-python/actions?query=workflow%3APublish) to make sure packages have been uploaded to PyPI |
| 47 | + * Check the release history (e.g. https://pypi.org/project/opentelemetry-api/#history) on PyPI |
| 48 | + * If for some reason the action failed, see [Publish failed](#publish-failed) below |
| 49 | +* Move stable tag |
| 50 | + * Run the following (TODO automate): |
| 51 | + ```bash |
| 52 | + git tag -d stable |
| 53 | + git tag stable |
| 54 | + git push --delete origin tagname |
| 55 | + git push origin stable |
| 56 | + ``` |
| 57 | + * This will ensure that READTHEDOCS for core are pointing at the stable release. |
| 58 | + * To validate this worked, ensure the stable build has run successfully: |
| 59 | + https://readthedocs.org/projects/opentelemetry-python/builds/. |
| 60 | + If the build has not run automatically, it can be manually trigger via the READTHEDOCs interface. |
39 | 61 |
|
40 | 62 | ## Notes about version numbering for stable components
|
41 | 63 |
|
|
68 | 90 | * The version number for unstable components in the `main` branch will be bumped to the next version,
|
69 | 91 | e.g. `0.{Y+1}b0.dev`.
|
70 | 92 |
|
71 |
| -## After the release |
72 |
| - |
73 |
| -* Check PyPI |
74 |
| - * This should be handled automatically on release by the [publish action](https://github.com/open-telemetry/opentelemetry-python/blob/main/.github/workflows/release.yml). |
75 |
| - * Check the [action logs](https://github.com/open-telemetry/opentelemetry-python/actions?query=workflow%3APublish) to make sure packages have been uploaded to PyPI |
76 |
| - * Check the release history (e.g. https://pypi.org/project/opentelemetry-api/#history) on PyPI |
77 |
| - * If for some reason the action failed, see [Publish failed](#publish-failed) below |
78 |
| -* Move stable tag |
79 |
| - * Run the following (TODO automate): |
80 |
| - ```bash |
81 |
| - git tag -d stable |
82 |
| - git tag stable |
83 |
| - git push --delete origin tagname |
84 |
| - git push origin stable |
85 |
| - ``` |
86 |
| - * This will ensure the docs are pointing at the stable release. |
87 |
| - * To validate this worked, ensure the stable build has run successfully: |
88 |
| - https://readthedocs.org/projects/opentelemetry-python/builds/. |
89 |
| - If the build has not run automatically, it can be manually trigger via the readthedocs interface. |
90 |
| - |
91 | 93 | ## Releasing dev version of new packages to claim namespace
|
92 | 94 |
|
93 | 95 | 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`.
|
|
0 commit comments