6.9 KiB
Release Process
This document describes the Release process followed by this Kubeflow Model Registry component project, enacted by its Maintainers.
Principles
The Kubeflow Model Registry follows the Github Release Workflow, and performs periodic releases in accordance with the Kubeflow Platform WG recommendations.
The Kubeflow Model Registry follows Semantic Versioning: MAJOR.MINOR.PATCH.
The Kubeflow Model Registry per governance of the Kubeflow Community, Kubeflow Platform WG, and KSC, releases as Alpha version, including the following statement:
> **Alpha**
> This Kubeflow component has alpha status with limited support. See the [Kubeflow versioning policies](https://www.kubeflow.org/docs/started/support/#application-status). The Kubeflow team is interested in your [feedback](https://github.com/kubeflow/model-registry/issues/new/choose) about the usability of the feature.
The Release of the Kubeflow Model Registry provides:
- a container image for the Backend; known as the "KF MR Go REST server"
- a Python client to be used in a Jupyter notebook, programmatically, or that can be integrated in the Kubeflow SDK; known as the "MR py client"
- an optional Model Registry Custom Storage Initializer container image for KServe; the "Model Registry CSI"
- a collection of Kubernetes Manifests, which get synchronized to the
kubeflow/manifestsrepository - an update to the Kubeflow website
Instructions
These instructions can be followed by the Maintainers with write access on the repository.
Assuming the following remotes are setup locally:
origin git@github.com:<your username>/model-registry.git (fetch)
origin git@github.com:<your username>/model-registry.git (push)
upstream git@github.com:kubeflow/model-registry.git (fetch)
upstream git@github.com:kubeflow/model-registry.git (push)
and for the rest of this instructions, the <your username> will be referred as mr_maintainer.
Prerequisites:
- on main branch, the version indicated by the pyproject.toml and metadadata of the Model Registry Python client is current (that is, is already valorized to the target release number).
- the main branch is up-to-date, all the required work has been already merged.
git checkout main
git pull upstream main
Example for 0.2.10 release:
VVERSION=v0.2.10
TDATE=$(date "+%Y%m%d")
[!NOTE] We no longer explicits the
-alphasuffix (see here).
- create the release branch upstream
git checkout -b release/$VVERSION
git push upstream release/$VVERSION
this creates the release branch upstream.
Create a PR to update what's needed on the release branch, i.e. to update the manifest images.
git checkout -b mr_maintainer-$TDATE-upstreamSync
pushd manifests/kustomize/base && kustomize edit set image ghcr.io/kubeflow/model-registry/server=ghcr.io/kubeflow/model-registry/server:$VVERSION && popd
pushd manifests/kustomize/options/csi && kustomize edit set image ghcr.io/kubeflow/model-registry/storage-initializer=ghcr.io/kubeflow/model-registry/storage-initializer:$VVERSION && popd
pushd manifests/kustomize/options/ui/base && kustomize edit set image model-registry-ui=ghcr.io/kubeflow/model-registry/ui:$VVERSION && popd
pushd manifests/kustomize/options/catalog/base && kustomize edit set image ghcr.io/kubeflow/model-registry/server=ghcr.io/kubeflow/model-registry/server:$VVERSION && popd
git add .
git commit -s
# suggested commit msg: "chore: align manifest for 0.2.10"
# using `git push origin`
# will give back convenient command on the screen for copy/paste:
# eg: git push --set-upstream origin mr_maintainer-20241108-upstreamSync
git push --set-upstream origin mr_maintainer-$TDATE-upstreamSync
-
create PR ⚠️ targeting the release branch ⚠️ specifically (title ~like:
chore: align manifest for 0.2.10) -
merge the PR (you can manually add the approved, lgtm labels)
-
optional. if you create the tag from local git (see point below); await GHA complete that push Container images to docker.io or any other KF registry: https://github.com/kubeflow/model-registry/actions
-
create the Release from GitHub, ⚠️ select the release branch ⚠️ , input the new tag
(in this example the tag is created from GitHub; alternatively, you could just do the tag manually by checking out the release branch locally--remember to pull!!--and issuing the tag from local machine). Encouraging in upstream to mark it as a non-production release (in the github screen). Encouraging to use the "alpha" version policy of KF in the beginning of the release markdown (see previous pre-releases).
It is helpful to prefix this in the release notes:
> **Alpha**
> This Kubeflow component has alpha status with limited support. See the [Kubeflow versioning policies](https://www.kubeflow.org/docs/started/support/#application-status). The Kubeflow team is interested in your [feedback](https://github.com/kubeflow/model-registry/issues/new/choose) about the usability of the feature.
- release the MR Python client
git checkout release/$VVERSION
git pull upstream release/$VVERSION
git tag py-$VVERSION
git push upstream py-$VVERSION
- add a Tag for the pkg/openapi
git checkout release/$VVERSION
git pull upstream release/$VVERSION
git tag pkg/openapi/$VVERSION
git push upstream pkg/openapi/$VVERSION
At this point, a release as been created, both the container images and the Python client on pypi.
KF/manifests
The KF/model-registry manifests need to be sync'd to KF/manifests repository using the Manifest/Platform WG provided script (in the KF/manifests repo).
Example PR:
It is supposed to work by leveraging sync script in KF/manifests repo:
KF/website
Update latest MR release version number in the KF/website repo.
Example PR:
Please notice the OpenAPI spec in the Reference section is automatically updated, since it is sourced from the repo: 23d50fea25/content/en/docs/components/model-registry/reference/rest-api.md (L44-L47)
Anticipate prerequisites
See at the beginning "Prerequisites", to facilitate the next round, now it's the best time:
- bump already MR py client to the next version, example PR https://github.com/kubeflow/model-registry/pull/871