chore: update CONTRIBUTING.md with revised release process steps

[ttypic]

update CONTRIBUTING.md with revised release process steps

Summary by CodeRabbit

• Documentation
  • Updated contribution/release guidelines: replaced automated build-and-publish-from-main with an explicit tag → GitHub release → approval-based publish workflow. Tagging and GitHub release remain; publishing to PyPI now requires manual approval. Changelog update guidance reordered to occur after release notes and simplified with an example.

[coderabbitai]

Walkthrough

The CONTRIBUTING.md release process was rewritten to remove direct build/publish steps and introduce a GitHub release → tag → approval workflow for PyPI publishing; the changelog update was retained and moved to after release notes with a simplified generator example.

Changes

Cohort / File(s)	Summary
Contribution guide CONTRIBUTING.md	Removed synchronous build/publish/tag steps (poetry build/publish, automatic tagging). Added guidance to create a GitHub release with a tag and use a Release Workflow that requires explicit approval before publishing to PyPI. Repositioned changelog update to occur after release notes and simplified the changelog-generator example (references v1.0.0).

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant ReleaseWF as Release Workflow
    participant PyPI as PyPI
    participant Changelog as Changelog

    Dev->>GH: Create tag & GitHub Release
    GH->>ReleaseWF: Trigger release workflow (await approval)
    Note over ReleaseWF: Approval required before publish
    ReleaseWF-->>PyPI: Publish package (post-approval)
    PyPI-->>ReleaseWF: Confirm publish
    Dev->>Changelog: Update changelog with release notes
    Changelog-->>Dev: Changelog updated

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Single documentation file changed.
• Verify clarity of new release-approval steps and that the changelog example matches repository conventions.
• Check no remaining references to the removed automated build/publish commands.

Poem

🐰 The tag I plant, the release I sing,

Approvals drum before bells ring.
Changelog hops in after the show,
Then PyPI welcomes what we sow. 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: updating CONTRIBUTING.md with revised release process steps, which aligns with the provided summary.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-contributing-guide

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

CONTRIBUTING.md (1)

45-48: Remove or reconcile duplicate changelog generator guidance.

Lines 45–48 duplicate the detailed changelog generator instructions already provided in step 4 (lines 33–37). The second block appears to be older, more generic guidance and creates confusion about which method to follow. Either remove this section or make it clear it's alternative/supplementary guidance for edge cases.

🧹 Nitpick comments (1)

CONTRIBUTING.md (1)

41-41: Clarify the release creation and tag timing.

The phrasing "including populating the release notes with creating a new tag" is awkward and leaves ambiguity about whether the tag should exist before this step or is created by the GitHub release action. Consider rewording to clarify the process (e.g., "Create a release on GitHub, which will create a new tag based on the version bump, and populate the release notes").

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 8021524 and 15ddb81.

📒 Files selected for processing (1)

• CONTRIBUTING.md (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

• GitHub Check: check (3.10)
• GitHub Check: check (3.13)
• GitHub Check: check (3.11)
• GitHub Check: check (3.9)
• GitHub Check: check (3.12)
• GitHub Check: check (3.7)
• GitHub Check: check (3.8)

[VeskeR]

I would keep a separate step for the tag so we have naming convention visible (e.g. including v before the version, we don't always do that across SDKs).
basically just keep:

Create a tag named like v2.0.1 and push it to GitHub - e.g. git tag v2.0.1 && git push origin v2.0.1

[ttypic]

fixed

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

CONTRIBUTING.md (1)

41-44: Approval-gated release workflow is well-structured.

The revised release process is clear: tag creation (8) → GitHub release (9) → approval gate for PyPI publishing (10) → external changelog (11). The workflow shift from automatic publish to manual approval is well-documented and the Release Workflow link is helpful.

Minor suggestion: Consider noting in step 9 whether the GitHub release should be created as a draft or pre-release until approval is granted in step 10, to avoid accidental public announcements before PyPI publishing is approved.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 15ddb81 and f7f4f6d.

📒 Files selected for processing (1)

• CONTRIBUTING.md (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

• GitHub Check: check (3.13)
• GitHub Check: check (3.7)
• GitHub Check: check (3.8)
• GitHub Check: check (3.9)
• GitHub Check: check (3.11)
• GitHub Check: check (3.12)
• GitHub Check: check (3.10)

🔇 Additional comments (1)

CONTRIBUTING.md (1)

41-41: Excellent: separate tag step with clear naming convention.

Step 8 now explicitly creates a tag with the naming convention clearly visible (v2.0.1). This directly addresses the previous feedback about maintaining a distinct tagging step with version naming guidelines.