Example Tagging Release #481
Conversation
WalkthroughThe pull request introduces updates to the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
.github/BRANCH_AND_RELEASE_PROCESS.md (3)
105-106: Fix inconsistent spacing in git push command.There's a double space in the command
git push upstream <version>.-git push upstream <version> +git push upstream <version>
96-107: Enhance command documentation with step explanations.While the commands are correct, adding brief comments explaining each step's purpose would improve clarity for users unfamiliar with git.
```bash # get the latest everything and update your fork git checkout main -git pull --rebase upstream main -git push -git fetch upstream --tags -git push origin --tags +git pull --rebase upstream main # Update local main with upstream changes +git push # Update your fork's main branch +git fetch upstream --tags # Fetch all tags from upstream +git push origin --tags # Sync tags to your fork # create a new tag following semver -git tag -m <version> <version> -git push upstream <version> +git tag -m <version> <version> # Create an annotated tag locally +git push upstream <version> # Push the new tag to upstream
124-128: Clarify when to use release branch process.While the document mentions security fixes as an example, it would be helpful to provide more specific guidance about when to use this process versus creating a release from main.
Consider adding a list of scenarios:
Common scenarios for creating releases from a release branch: - Critical security vulnerabilities requiring immediate patches - Customer-specific hotfixes for older supported versions - Compatibility fixes for specific SDK versions
Proposed changes
Document actual
gitcommands for performing a release.Types of changes
What types of changes does your code introduce to the community Python SDK?
Put an
xin the boxes that applyChecklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
Summary by CodeRabbit