small change proposal for Release process/pypi version
Collected the experience from the previous periodic releases of Model Registry so far: https://github.com/kubeflow/model-registry/releases
the following small changes are being proposed, to go into effect at the next feasible periodic release:
- make a
release/v0.2.x-alphabranch, and tag from that "release branch" - introduce "pinning" changes for the manifest, similar to this example
- drop the
.a1suffix for the Model Registry python client
What is NOT changing
- Model Registry is still Alpha:
- as highlighted in the website,
- and on the Model Registry Python client readme
- dev workflow still refer to
mainbranch,- any PR will be opened targeting
maindefault branch
- any PR will be opened targeting
- there is no "support requirement" for "release branches", likewise of Kubeflow versioning scheme: the release branches are introduced to allow image version "pinning" or any other chore commit required on the repo before a given Alpha release
Why these changes
These changes are being proposed for the following reasons:
- introduce image version "pinning" in the manifest, and potentially later any other "pinning" requirements in a dedicated branch
- make it easier to sync accordingly to KF/manifests repo
- lower friction when browsing pypi, and when installing from pypi
don't forget to comment or emoji react for your thoughts! (thanks @Al-Pragliola for the 👀 )
+1 Having a brach for the release will also provide us to release z stream release from the branch created to cover any CVEs or critical bugs.
@kubeflow/release-team @rimolive during last KF biweekly meeting 2024-09-30, a question was raised whether we "have to" keep the -alpha suffix also for the container images: https://hub.docker.com/r/kubeflow/model-registry/tags?name=v0
after all, they start with v0. and we document we're in Kubeflow Alpha designation per resources above:
- Model Registry is still Alpha:
- as highlighted in the website,
- and on the Model Registry Python client readme
what are your thoughts, please?
Historically, component owners in past Kubeflow releases used both ways. The Katib team used not only the -alpha suffix but also what I believe is the commit hash that image was built into.
On the other hand, Pipelines team decided on a different approach by just tagging images with their respective version without include alpha or beta in the image tag.
I think the most important action here is how the message about the alpha status for Model Registry is clear and transparent to the users. We've been talking about the alpha status in many community meetings, we wrote a blog post, and the documentation makes it clear that MR is still under alpha.
That said, I'm okay to just use the version without the -alpha suffix in the image tags since the message here is clear: We'll reach final or GA only when image tags reach 1.0.0.
+1 for that. This will become useful for CVEs and backporting of critical issues.
with 0.2.8-alpha, I've seized the chance to test the release branch strategy from the original https://github.com/kubeflow/model-registry/issues/435#issue-2556426644
- release: https://github.com/kubeflow/model-registry/releases/tag/v0.2.8-alpha
- release branch: https://github.com/kubeflow/model-registry/tree/release/v0.2.8-alpha
- tag is on the release branch.
with 0.2.9, I've seized the chance to further progress on the release branch strategy from the original https://github.com/kubeflow/model-registry/issues/435#issue-2556426644
- release: https://github.com/kubeflow/model-registry/releases/tag/v0.2.9
- release branch: https://github.com/kubeflow/model-registry/tree/release/v0.2.9
- tag is on the release branch,
- py client omits the
.a1suffix, - image omits
-alphasuffix as requested and relies on the Alpha disclaimer in website, and on the Model Registry Python client readme and on the repo readme
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity. Please comment "/reopen" to reopen it.