small change proposal for Release process/pypi version

[tarilabs]

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-alpha branch, and tag from that "release branch"
• introduce "pinning" changes for the manifest, similar to this example
• drop the .a1 suffix 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 main branch,
  • any PR will be opened targeting main default branch
• 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 👀 )

[rareddy]

+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.

[tarilabs]

@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?

[rimolive]

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.

[ederign]

+1 for that. This will become useful for CVEs and backporting of critical issues.

[tarilabs]

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.

[tarilabs]

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 .a1 suffix,
• image omits -alpha suffix as requested and relies on the Alpha disclaimer in website, and on the Model Registry Python client readme and on the repo readme