From b0e7fb24a763b1b3e7f44ab634cd5685de69f992 Mon Sep 17 00:00:00 2001 From: Leighton Chen Date: Wed, 13 Nov 2024 15:30:55 -0800 Subject: [PATCH 1/3] Update RELEASING.md --- RELEASING.md | 49 ++++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 09e23ba357..1bca4ad9c4 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -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. + * 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 @@ -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. + * 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 @@ -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`. From ec00e2bbf09cfecc4e88deeb51f71cc2fdfb4b92 Mon Sep 17 00:00:00 2001 From: Leighton Chen Date: Thu, 14 Nov 2024 08:54:04 -0800 Subject: [PATCH 2/3] Update RELEASING.md Co-authored-by: Riccardo Magliocchetti --- RELEASING.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 1bca4ad9c4..46fbdfd9a1 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -9,7 +9,10 @@ (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`). - * 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. + * 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 CONTRIB_REPO_SHA of core PRs to point to their counterpart in contrib. + * Change the CORE_REPO_SHA of contrib PRs to point to their counterpart in core. + * Release builds now should pass. * Merge the release PR. * Merge the PR to main (this can be done separately from [making the release](#making-the-release)) From 5350d55e7f43f3f30842d5407c24d266dbe94762 Mon Sep 17 00:00:00 2001 From: Leighton Chen Date: Thu, 14 Nov 2024 08:54:11 -0800 Subject: [PATCH 3/3] Update RELEASING.md Co-authored-by: Riccardo Magliocchetti --- RELEASING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASING.md b/RELEASING.md index 46fbdfd9a1..f1c8e4aa69 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -54,7 +54,7 @@ git push --delete origin tagname git push origin stable ``` - * This will ensure that READTHEDOCs for core are pointing at the stable release. + * This will ensure that READTHEDOCS for core 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.