|
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