Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit a94eab9

Browse files
authored
Update RELEASING.md (open-telemetry#4274)
1 parent 6fdaf44 commit a94eab9

File tree

1 file changed

+27
-25
lines changed

1 file changed

+27
-25
lines changed

RELEASING.md

Lines changed: 27 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,12 @@
99
(otherwise the workflow will pick up the version from `main` and just remove the `.dev` suffix).
1010
* Review the two pull requests that it creates.
1111
(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))
1418

1519
## Preparing a new patch release
1620

@@ -33,9 +37,27 @@
3337
* Press the "Run workflow" button, then select the release branch from the dropdown list,
3438
e.g. `release/v1.9.x`, and click the "Run workflow" button below that.
3539
* 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.
3961

4062
## Notes about version numbering for stable components
4163

@@ -68,26 +90,6 @@
6890
* The version number for unstable components in the `main` branch will be bumped to the next version,
6991
e.g. `0.{Y+1}b0.dev`.
7092
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-
9193
## Releasing dev version of new packages to claim namespace
9294
9395
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

Comments
 (0)