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.

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

Example Tagging Release #481

Merged
merged 1 commit into from
Nov 5, 2024
Merged
Changes from all commits
Commits
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
53 changes: 53 additions & 0 deletions .github/BRANCH_AND_RELEASE_PROCESS.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,3 +86,56 @@ 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-python-sdk/releases).

davidvonthenen marked this conversation as resolved.
Show resolved Hide resolved
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>
```

If the release you want to create is `v3.9.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 v3.9.0 v3.9.0
git push upstream v3.9.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.

davidvonthenen marked this conversation as resolved.
Show resolved Hide resolved
If this were the `release-v2` branch for version `v2.5.1` (note the `v2` matches the `release-v2`), this would look like (again, assuming you are on your fork):

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

# create a new tag following semver
git tag -m v2.5.1 v2.5.1
git push upstream v2.5.1
```
Loading