Skip to content

Commit

Permalink
chore: add release documentation (numaproj#155)
Browse files Browse the repository at this point in the history
Signed-off-by: a3hadi <[email protected]>
  • Loading branch information
ayildirim21 authored Apr 12, 2024
1 parent af095a1 commit 1a3c0b8
Show file tree
Hide file tree
Showing 2 changed files with 32 additions and 12 deletions.
15 changes: 3 additions & 12 deletions development.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,20 +39,11 @@ Note: before running the script, ensure that through the CLI, you are logged int

After confirming that your changes pass local testing:
1. Clean up testing artifacts (remove any `dist/` folders created, remove any test images on quay.io, etc.)
2. Create a PR for your changes. Once your PR has been merged, a Github Actions workflow (Docker Publish) will be triggered, to build, tag (with `stable`), and push
2. Create a PR for your changes. Once your PR has been merged, a Github Actions workflow (`Docker Publish`) will be triggered, to build, tag (with `stable`), and push
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

### Before Release

Before releasing a new SDK version, make sure to update all references from the old version to the new one. For example,
the version in the root `pyproject.toml` should be updated (for [reference](https://github.com/numaproj/numaflow-python/commit/6a720e7c56121a45b94aa929c6b720312dd9340a)),
which can be done by running `poetry version <new-version>`.
After making these changes, create a PR. Once merged, it will trigger the Docker Publish workflow, and should be included in the release.
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 referencing the local SDK tarball that is built).

### 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 `example_directories` matrix in `build-push.yaml`.
If you add a new example, in order for it to be used by the `Docker Publish` workflow, add its path
to the `example_directories` matrix in `.github/workflows/build-push.yaml`.
29 changes: 29 additions & 0 deletions releases.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Release Guide

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

### Before Release

1. Before releasing a new SDK version, make sure to update all references from the old version to the new one. For example,
the version in the root `pyproject.toml` should be updated (for [reference](https://github.com/numaproj/numaflow-python/commit/6a720e7c56121a45b94aa929c6b720312dd9340a))
- The version in the root `pyproject.toml`
can be updated by running `poetry version <version-bump-rule | PEP440-string>`. The version bump rules that can be provided and their corresponding effects can be found [here](https://python-poetry.org/docs/cli/#version),
in the `Poetry` documentation. A version number can also be directly specified instead, but it must follow the [PEP 440](https://peps.python.org/pep-0440/) specification
2. If the version to be released has backwards incompatible changes, i.e. it does not support older versions of the Numaflow platform,
you must update the `MINIMUM_NUMAFLOW_VERSION` constant in the `pynumaflow/info/types.py` file to the minimum Numaflow version that is supported by your new SDK version
3. After making these changes, create a PR. Once merged, it will trigger the `Docker Publish` workflow, and should be included in the release.
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 referencing the local SDK tarball that is built)

### How to Release

This can be done via the Github UI.
1. In the `Releases` section of the Python SDK repo, click `Draft a new release`
2. Create a tag that has the same name as the version that you specified in the root
`pyproject.toml`, prefix it with a `'v'`, and select it
3. Make the title the same as the tag
4. 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
5. Select `Set as the latest release` or `Set as a pre-release`, depending on your situation
6. Finally, click `Publish release`, and your version tag will be the newest release on the repository

0 comments on commit 1a3c0b8

Please sign in to comment.