Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Example Tagging Release #351

Merged
merged 2 commits into from
Nov 5, 2024
Merged

Example Tagging Release #351

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4329da9
Example Tagging Release
davidvonthenen Nov 4, 2024
7f80135
Update .github/BRANCH_AND_RELEASE_PROCESS.md
davidvonthenen Nov 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions .github/BRANCH_AND_RELEASE_PROCESS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,3 +86,55 @@ In the event of a breaking interface change, a `release-v[0-9]+` branch is creat
In scenarios where urgent issues arise, the `hotfix` branch comes into play. A hotfix branch is created off main or the relevant release branch to address critical issues that need immediate attention. After the hotfix is implemented and thoroughly tested, it is merged back into both the `main` and the `release-v[0-9]+` branches to ensure the fix is included in the current and future versions of the project.

This dual approach of leveraging both **GitHub Flow** and **Git Flow** ensures that the project can iterate quickly while maintaining high standards of code stability and release management.
### Creating a Release

Since the latest stable code is contained on `main` in a typical **GitHub Flow**, to create a release someone with write access to the repository needs to simply just `git tag` the release and then create a (draft) release using that tag in the [repository's release page](https://github.com/deepgram/deepgram-dotnet-sdk/releases).

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:

```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>
```
davidvonthenen marked this conversation as resolved.
Show resolved Hide resolved
Comment on lines +95 to +106
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ 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 -->


If the release you want to create is `4.5.0`, then this would look like:

```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 4.5.0 4.5.0
git push upstream 4.5.0
```

#### Creating a Release from a Release Branch

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.

Comment on lines +125 to +126
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ 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.

Suggested change
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.

If this were the `release-v3` branch for version `3.4.3` (note the `3` matches the `release-v3`), this would look like (again, assuming you are on your fork):

```bash
# get the latest everything and update your fork
git checkout release-v3
git pull --rebase upstream release-v3
git push origin release-v3
git fetch upstream --tags
git push origin --tags

# create a new tag following semver
git tag -m 3.4.3 3.4.3
git push upstream 3.4.3
```
davidvonthenen marked this conversation as resolved.
Show resolved Hide resolved
Loading