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

chore: add release documentation #117

Merged
merged 3 commits into from
Apr 10, 2024
Merged

chore: add release documentation #117

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
69b4cd5
chore: add release documentation
ayildirim21 Apr 10, 2024
76a8827
update releases.md
ayildirim21 Apr 10, 2024
e0306e4
update releases.md
ayildirim21 Apr 10, 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
13 changes: 1 addition & 12 deletions development.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,18 +35,7 @@ After confirming that your changes pass local testing:
all example images. This ensures that all example images are using the most up-to-date version of the SDK, i.e. the one including your
changes.

### After release

Once a new version has been released, and its corresponding version tag exists on the remote repo, you want to update the `go.mod`
files to reflect this new version:
```shell
./hack/update_examples.sh -u <version>
```
After running the above, create a PR for the changes that the script made. Once merged, it will trigger the Docker Publish workflow.
As a result, the correct SDK version will always be printed in the server information logs,
and the example images will always be using the latest changes (due to the local references).

### Adding a New Example

If you add a new example, in order for it to be used by the Docker Publish workflow, add its path
to the `dockerfile_paths` matrix in `build-push.yaml`.
to the `dockerfile_paths` matrix in `.github/workflows/build-push.yaml`.
24 changes: 24 additions & 0 deletions releases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Release Guide

This document explains the release process for the Go SDK. You can find the most recent version under [Github Releases](https://github.com/numaproj/numaflow-go/releases).

### How to Release

This can be done via the Github UI. In the `Releases` section of the Go SDK repo, click `Draft a new release`. Create an appropriate tag for the new version and select it. Make
the title the same as the tag. Click `Generate release notes` so that all the changes made since the last release are documented. If there are any major features or breaking
changes that you would like to highlight as part of the release, add those to the description as well. Then set the release as either pre-release or latest, depending
on your situation. Finally, click `Publish release`, and your version tag will be the newest release on the repository.

### After Release

Once a new version has been released, and its corresponding version tag exists on the remote repo, you want to update the `go.mod`
files to reflect this new version:
```shell
./hack/update_examples.sh -u <version>
```
After running the above, create a PR for the changes that the script made. Once merged, it will trigger the Docker Publish workflow.
As a result, the correct SDK version will always be printed in the server information logs,
and the example images will always be using the latest changes (due to the local references).

If the released version has backwards incompatible changes, i.e. it does not support older versions of the Numaflow platform,
you must update the `MinimumNumaflowVersion` constant in the `pkg/info/types.go` file to the minimum Numaflow version that is supported by your new SDK version.
Loading