Use Semantic Versions for releases

[EngHabu]

I don't get why are we using the weird notion of kubernetes- that breaks Go Dep sem-version matching logic... was there a reason behind it or just evolved that way?

[nikhita]

I'm not sure of the history behind apimachinery releases but we do have semantic versioning for client-go. @sttts do you know why we choose to follow semver only for client-go?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[EngHabu]

@sttts... Any ideas?

[QuLogic]

Also troublesome for Go modules, which mandate names like v1.2.3.

[EngHabu]

/remove-lifecycle stale

[EngHabu]

@caesarxuchao @sttts ?

[seenickcode]

Would you have any update on this @EngHabu , @caesarxuchao or @sttts ?

[EngHabu]

Unfortunately I'm not a maintainer @seenickcode, so I don't really have control one way or another...
I strongly vote for ditching kubernetes-* scheme and just stick with proper semantic versioning... it also seems that dropping kubernetes-* might not be enough... I've seen breaking changes between 1.n and 1.n+1 versions.. breaking changes should bump the major version and shouldn't be taken lightly..

@nikhita, unfortunately, client-go has the same problem... kubernetes-1.10.5 is not a proper semantic version... it almost is but in factuality isn't. If this is in your control, please do start following https://semver.org/ to the letter... or at least let us know how can we make progress on this issue... I'm not so familiar with the triage process for the different sigs... is this the right forum to make such a determination? do I need to open a PR somewhere to get votes? whatever it's, I, and I'm sure others on this thread, would appreciate some clarity here...

[sttts]

Not having semantic versions is intentional. We want them eventually, but are not able to provide a smooth go.mod experience for a number of reasons. That's why we are holding back tagging all repos as v15.0.0.

One of the issues: we probably have to move to versioned imports. This is non-trivial to do while publishing.

tl/dr: we are not moving forward with semver tags before we are sure it gives the right experience with go.mod.

[nrvnrvn]

as far as I can tell kubernetes itself works around the issue by referring to filesystem, i.e. https://github.com/kubernetes/kubernetes/blob/v1.15.0/go.mod#L433

The problem is with those who want to use k8s.io/apimachinery or k8s.io/api as an external dependency. It ends up with records like k8s.io/apimachinery => k8s.io/apimachinery v0.0.0-20190221213512-86fb29eff628 in go.mod with comments like // Pinned to kubernetes-1.13.4

@sttts what is the benefit of versioned imports over semversioned go.mod references?

[sttts]

They are the only way to use go.mod the way it is supposed to be used, without having replace directives in your go.mod. We have to do that switch eventually.

[EngHabu]

Do you mind elaborating on the "versioned imports" issue you referred to @sttts? as well as the other issues blocking this move? is that documented somewhere? is it something we can help with? is it going to be some routine work for a relatively short period of time that will make everyone else's life easier?

[liggitt]

Do you mind elaborating on the "versioned imports" issue you referred to @sttts? as well as the other issues blocking this move?

See discussion in kubernetes/publishing-bot#196

The likely result is that all import paths for all published kubernetes dependencies change every release (e.g. to k8s.io/client-go/v15/..., k8s.io/client-go/v16/..., etc)

is that documented somewhere?

• discussion of the concept is at https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• discussion of the tradeoffs for use within kube at https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/2019-03-19-go-modules.md#alternative-versioning-strategies

is it something we can help with?

something like kubernetes/publishing-bot#196 is the likely place for the work

is it going to be some routine work for a relatively short period of time that will make everyone else's life easier?

It's hard to tell if frequent disruptive widespread import changes will make everyone else's life easier or not. The work to set up the system that produces those published repos should be short-lived, but once committed to that path, the changes for consumers that actually want to use latest kubernetes libraries are ongoing.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nrvnrvn]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

Closing in favour of kubernetes/kubernetes#72638

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

Closing in favour of kubernetes/kubernetes#72638

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.