[Discussion] Time to start tagging releases for the TF operator?

[ConnorDoyle]

Several documented examples depend on an unversioned tarball URL.

In order to:

• make demos more reproducible
• speak clearly about when changes happened
• make organized progress toward 1.0
• begin building release capabilities among the contributors

it would be great for this project to begin tagging pre-release (v0.x.x) versions.

[jlewi]

What are the examples referring to an versioned tarball?

The way things are currently setup, we release versioned tarballs on each passing post-submit. So in principle the commit hash is the tag.

The suggestion in the docs is to pick a particular version and control when you upgrade. Is that not sufficient?

Does tagging releases imply some manual release qualification?

[ConnorDoyle]

What are the examples referring to an [un]versioned tarball?

From the README, this is the first thing I saw as a user coming to the project.

CHART=https://storage.googleapis.com/tf-on-k8s-dogfood-releases/latest/tf-job-operator-chart-latest.tgz
helm install ${CHART} -n tf-job --wait --replace --set rbac.install=true,cloud=<gke or azure>

While it's true you can get a tarball for an arbitrary commit, this isn't very user friendly. For one, a commit sha doesn't convey much information (ordering, relative distance from another tarball, alpha vs pre-alpha state, etc.)

Here's one scenario: If I look at a deployment of the operator and find a given hash, I need to dig through git to figure out my image/chart should have the fix for the bug I'm observing.

During the community call last week we discussed targeting "v1.0" in O(months). I don't think it's feasible to argue against semantic versioning past that point. So this is really just a request to start that process a bit earlier. Another way to look at this is that release practices are like a muscle that needs to be trained; it's difficult for a project to go directly from no-versions to strong semver.

Does that make sense? This is mostly a usability annoyance that I experienced coming to the project that I'd like to help fix.

[ScorpioCPH]

it's difficult for a project to go directly from no-versions to strong semver.

+1

@aronchick How about add this topic in the governance and process proposal which we planned to do at kick-off meeting last week?

[jlewi]

I agree about moving to semver; I was thinking that we'd call may a 0.1.0 release.

I'm happy to start introducing more convenient user tags before than.

The main thing is I'd like our release process and tagging to be automated rather than getting into the habit of doing manual, human qualified releases.

So I'm fully supportive if someone wants to improve are release process to

• Use semver or other friendly tagging mechanism
• Push release notes

[ConnorDoyle]

Definitely +1 for automating this.

[jlewi]

Our release tooling as it is consists of the script which gets the latest green and builds, pushes the artifacts.

• This runs as a cron job in a dedicated K8s cluster

I think an obvious improvement would be to add a releases web page (#70) where users could go to find and download the latest release.

I looked a bit to see if there was a release tool out there (e.g. GitLab that was Kubernetes native but couldn't find one. I'd prefer not to have to learn new abstractions/APIs for things that are well represented in K8s (e.g. process management).

My current thinking was that we'd just have a set of python scripts and then we could build a release workflow using Argo.

I'm open to suggestions though.

However, I think scripts + Argo should be sufficient if someone wanted to take on #70 and create a releases page.

[jlewi]

Adding this to the Kubecon Europe milestone because I think we should switch to semver by then. I also added #70 to the milestone.

Lets try to reach a consensus though on what specifically we want to get done by Kubecon? Other than adding a releases page and switching to semver tagging is there anything else?

Some questions about versioning

• How do we map semver to K8s API versioning?
  • Pattern in K8s is v1alpha1, v1beta2, v1?

[jlewi]

I think we should close this in favor of kubeflow/kubeflow#215

I think the ksonnet configs are the things we want to tag and pin since those are what we expect users to interact with.

[jlewi]

Duplicate of kubeflow/kubeflow#215