ci: port package release workflows from contrib

[MikeGoldsmith]

Summary

Repurposes the original RELEASING.md PR per @lmolkova's feedback ("can we just port them? I don't think we should ever release manually"). Ports the per-package release workflows from opentelemetry-python-contrib instead of documenting a manual flow. Now that #16 (towncrier) has landed, the workflows' changelog steps work as-is.

Every publishable package in this repo is independent (per eachdist.ini [exclude_release]), so only the per-package contrib workflows apply.

What's in this PR

Workflows under .github/workflows/:

• package-prepare-release.yml — cuts package-release/<pkg>/v<X>.<Y>.x, opens two PRs (release branch + main).
• package-prepare-patch-release.yml — opens a patch-bump PR against an existing release branch.
• package-release.yml — builds the wheel, publishes to PyPI, creates the GitHub release, back-merges the changelog to main.

Scripts under scripts/ and .github/scripts/:

• generate_release_notes.sh
• merge_changelog_to_main.sh
• .github/scripts/use-cla-approved-github-bot.sh

RELEASING.md rewritten as a thin doc pointing at the workflows, with sections for: prerequisites, minor/major flow, patch flow, the static ## Unreleased folding caveat, and troubleshooting.

Adaptations from contrib

• Package dropdowns in all 3 workflows list this repo's 8 publishable packages (instead of contrib's 11).
• backport.yml not ported — no release branches exist yet; will revisit when one does. Tracked in Bootstrap opentelemetry-python-genai repo #15.
• PyPI publishing uses a token (secrets.pypi_password), matching contrib. Tracked in Bootstrap opentelemetry-python-genai repo #15 to migrate to PyPI trusted publishing once package names are decided.

Prerequisites (not blocking this PR, but blocking actual use)

• OTELBOT_APP_ID variable + OTELBOT_PRIVATE_KEY secret — configured by maintainers.
• pypi_password secret — needs a PyPI token once PyPI package names are decided.
• Branch protection on package-release/*/v* branches.

All called out in RELEASING.md.

Verification

• Grepped for contrib-specific strings (opentelemetry-python-contrib, contrib's release/v*-0.*bx, contrib package names) across the new files — clean.
• Confirmed eachdist.py find-package --package <name> and eachdist.py version --package <name> both work for all 8 packages.
• Confirmed every package's current version matches the regex patterns used in the workflows (mix of X.YbN.dev and X.Y.Z.dev).

Workflow execution can't be exercised end-to-end until otelbot + PyPI auth are configured. That's a maintainer setup task, out of scope here.

Notes

• Skip Changelog label applied (CI/tooling change).
• @lmolkova — pinging since this is the response to your earlier review feedback.

CI failures unrelated to this PR

misc / typecheck and several instrumentation-{anthropic,openai-v2}-latest jobs are red on this PR, but the failures are pre-existing on main:

• typecheck: pyright flags existing # pyright: ignore and cast() calls in util/opentelemetry-util-genai/src/opentelemetry/util/genai/completion_hook.py as unnecessary. Same root cause as the contrib issue fixed in opentelemetry-util-genai: fix typecheck after importlib metadata shim changes opentelemetry-python-contrib#4585; the genai equivalent hasn't been done. Worth opening a separate fix PR.
• instrumentation-*-latest tests: ModuleNotFoundError: No module named 'opentelemetry.exporter' during test_conformance.py collection. Likely a missing test dep introduced after the last green main run.

This PR only touches .github/workflows/package-*.yml, .github/scripts/use-cla-approved-github-bot.sh, scripts/{generate_release_notes,merge_changelog_to_main}.sh, and RELEASING.md — none of which can affect those CI jobs.

[Copilot]

Pull request overview

Adds release-process documentation for the repository’s independent per-package release model, including manual release steps while automated release workflows are still pending.

Changes:

• Adds RELEASING.md with publishable package list and release flow.
• Documents changelog, version bump, tagging/building, PyPI upload, GitHub release, and next-dev-version steps.
• Captures missing release infrastructure tracked by #15.

Comments suppressed due to low confidence (3)

RELEASING.md:98

• The release-notes extraction command does not extract the release body. In awk range patterns, the end pattern ^## also matches the starting ## Version <version> line, so the range ends on the same line and sed '$d' removes the only line. Maintainers following this command would create a GitHub release with empty notes.

  --notes-file <(awk '/^## Version <version>/,/^## /{print}' <package>/CHANGELOG.md | sed '$d')

RELEASING.md:76

• This uses <pypi-name> as PACKAGE_NAME, but scripts/build_a_package.sh uses PACKAGE_NAME to locate **/$pkg_name/pyproject.toml. The document also says the PyPI names will differ from the current package directories, so the documented command will fail unless the directory/project name matches the PyPI name or the build script is updated.

PACKAGE_NAME=<pypi-name> VERSION=<version> ./scripts/build_a_package.sh

RELEASING.md:120

• The stated unstable version pattern does not match several current package versions (for example, anthropic/langchain/weaviate use 2.0b0.dev, google-genai uses 2.5b0.dev, and openai-agents-v2 uses 0.2.0.dev). Following this section as written could cause maintainers to bump releases to the wrong version scheme.

- **Unstable components** (everything currently in this repo): versions look
  like `0.Yb0.dev` on `main`, `0.Yb0` at release time, then bump to
  `0.{Y+1}b0.dev`.

[MikeGoldsmith]

I think this is ready for another review please @lmolkova @JWinermaSplunk 👍🏻

[JWinermaSplunk]

Apologies if I am wrong, but I rechecked scripts/build_a_package.sh and it calls uv run and uv build not python3 -m build. Is this expected?

Unsure about this, but looks good otherwise!