Example Tagging Release #351
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: 3
🧹 Outside diff range and nitpick comments (3)
.github/BRANCH_AND_RELEASE_PROCESS.md (3)
93-94: Add prerequisite about upstream remote setupThe commands assume the upstream remote is configured, but this should be explicitly mentioned as a prerequisite.
Add this note before the commands:
+> **Note:** These commands assume you have already set up an `upstream` remote pointing to the main repository. If you haven't, run: +> ```bash +> git remote add upstream https://github.com/deepgram/deepgram-dotnet-sdk.git +> ``` +🧰 Tools
🪛 LanguageTool
[uncategorized] ~93-~93: Possible missing comma found.
Context: ... commands to execute at the root of the repository assuming you are on your fork: ```bash...(AI_HYDRA_LEO_MISSING_COMMA)
125-126: Add guidance on release branch creationThe section explains how to use release branches but doesn't mention when and how to create them.
Consider adding:
While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), there are times when you need to provide a patch release for things like security fixes. To create that patch releases, you do something similar as you would have done on main, but on the `release-v[0-9]+/*` branch. +To create a new release branch: +```bash +git checkout main +git checkout -b release-v3 +git push upstream release-v3 +``` +
93-93: Add missing commaAdd a comma for better readability.
-If you haven't done this before, these are the typicial commands to execute at the root of the repository assuming you are on your fork: +If you haven't done this before, these are the typicial commands to execute at the root of the repository, assuming you are on your fork:🧰 Tools
🪛 LanguageTool
[uncategorized] ~93-~93: Possible missing comma found.
Context: ... commands to execute at the root of the repository assuming you are on your fork: ```bash...(AI_HYDRA_LEO_MISSING_COMMA)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/BRANCH_AND_RELEASE_PROCESS.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
.github/BRANCH_AND_RELEASE_PROCESS.md
[uncategorized] ~93-~93: Possible missing comma found.
Context: ... commands to execute at the root of the repository assuming you are on your fork: ```bash...
(AI_HYDRA_LEO_MISSING_COMMA)
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/BRANCH_AND_RELEASE_PROCESS.md(1 hunks)
🔇 Additional comments (1)
.github/BRANCH_AND_RELEASE_PROCESS.md (1)
137-140: 🛠️ Refactor suggestion
Add security backporting instructions.
For security fixes, it's crucial to ensure changes are also applied to the main branch.
# create a new tag following semver
git tag -m 3.4.3 3.4.3
+# verify the tag
+git show 3.4.3
git push upstream 3.4.3
+
+# For security fixes, ensure changes are backported to main
+git checkout main
+git pull upstream main
+git cherry-pick <commit-hash> # or create a PR to merge from release-v3
+git push upstream mainLikely invalid or redundant comment.
| ```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 | ||
|
|
||
| # create a new tag following semver | ||
| git tag -m <version> <version> | ||
| git push upstream <version> | ||
| ``` |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add safety checks and verification steps to the release process.
The commands are correct but could benefit from additional safety measures:
```bash
# get the latest everything and update your fork
git checkout main
+# ensure we are up-to-date and there are no uncommitted changes
+git status
git pull --rebase upstream main
git push
git fetch upstream --tags
git push origin --tags
# create a new tag following semver
git tag -m <version> <version>
+# verify the tag was created correctly
+git show <version>
git push upstream <version>
+# verify the tag was pushed successfully
+git ls-remote --tags upstream
<!-- This is an auto-generated comment by CodeRabbit -->
| While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), there are times when you need to provide a patch release for things like security fixes. To create that patch releases, you do something similar as you would have done on main, but on the `release-v[0-9]+/*` branch. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Clarify security implications and patch release criteria.
The explanation of when to create patch releases could be more specific about security implications.
-While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), there are times when you need to provide a patch release for things like security fixes. To create that patch releases, you do something similar as you would have done on main, but on the `release-v[0-9]+/*` branch.
+While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), patch releases should be created in specific circumstances:
+1. Critical security vulnerabilities that affect user safety
+2. Severe bugs that impact core functionality
+3. Dependency updates addressing known vulnerabilities
+
+To create these patch releases, follow the same process as main but on the `release-v[0-9]+/*` branch.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), there are times when you need to provide a patch release for things like security fixes. To create that patch releases, you do something similar as you would have done on main, but on the `release-v[0-9]+/*` branch. | |
| While we don't have a formal requirement for supporting past releases (ie currently on `v3` but need a patch on `v2`), patch releases should be created in specific circumstances: | |
| 1. Critical security vulnerabilities that affect user safety | |
| 2. Severe bugs that impact core functionality | |
| 3. Dependency updates addressing known vulnerabilities | |
| To create these patch releases, follow the same process as main but on the `release-v[0-9]+/*` branch. |
Proposed changes
Document actual
gitcommands for performing a release.Types of changes
What types of changes does your code introduce to the community .NET 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
NA
Summary by CodeRabbit