Use semantic import versioning for published staging repos

[nikhita]

Published staging repos like kubernetes/api, etc have tags like kubernetes-1.13.1 which correspond to the v1.13.1 tag in kubernetes/kubernetes. Due to the kubernetes- prefix, tools like dep don't pick up the new version.

We could start using semantic versioning for tags in published repos as well. One way to do that (as pointed by @sttts on slack) is to have the tags as 13.0.1. This is also a faithful representation of our compatibility guarantees.

This would require a change to the publishing-bot.

/sig api-machinery
/sig release
/area release-infra
/cc @sttts @pohly @lavalamp @deads2k @liggitt

[pohly]

I understand that each new Kubernetes release must bump the major version of the mirrored repos, because in each major release new features might have been added and there might have been breaking API changes.

Is that what is meant with the compatibility guarante, i.e. it is not about the compatibility of some Kubernetes client built using these repos and the next Kubernetes release?

I'm fine with using 13.0.1, I'm just trying to understand.

[neolit123]

repos like kubernetes/api, etc have tags like kubernetes-1.13.1 which correspond to the v1.13.1 tag in kubernetes/kubernetes

this ain't good.

is to have the tags as 13.0.1

and it will break once k8s 2.0.0 is out?

[pohly]

When k8s 2.0.0 comes along, the mirrored repos can switch to 100.0.0 and then increment major by one for following releases.

[fedebongio]

/cc @caesarxuchao

[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]

/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

[neolit123]

We could start using semantic versioning for tags in published repos as well. One way to do that (as pointed by sttts on slack) is to have the tags as 13.0.1. This is also a faithful representation of our compatibility guarantees.

one question i had there is what happens once the k8s MAJOR becomes 2.

[neolit123]

/remove-lifecycle stale

[nikhita]

one question i had there is what happens once the k8s MAJOR becomes 2.

I believe the idea is v215.0.1 for v2.15.1 of k/k. cc @sttts

[nikhita]

xref kubernetes/publishing-bot#196

[neolit123]

given k/k is not following semver directly (breaking api changes for MINOR), i don't see why we should diverge the staging repos to comply with semver and have different tags - i.e. why not simply do 1to1 mapping and have breaking API changes in MINORs there too?

[nikhita]

why not simply do 1to1 mapping and have breaking API changes in MINORs there too?

k/k is not expected to be imported directly so it doesn't matter if it doesn't respect semver. However, the published repos are expected to be imported and if we want to use versioned imports for it, we need to respect semver because versioned imports will have the major version in the import paths. And users will be expected to update their import paths only when there are breaking changes.

[neolit123]

i see, so it's a problem with the semantic MAJOR imports go does.
in any case, v215.0.1 or 15.0.1 will surely end up as being confusing.

[pohly]

This leads to the next question: will the published packages use versioned imports themselves?

If I import one package, the expectation is that it imports the correct version of all its dependencies.

[neolit123]

if someone starts doing v15/ imports it means they have to update their imports on a much higher rate because this v15 maps to a MINOR behind the lines that updates every 3 months.

the diffs for such changes will be big and frequent.

versioned imports have the benefits of mixing APIs and code from different MAJORs, but do we have use cases for that outside of core (v1)? the alternative the users have here is pinning at the go.mod side, which is certainly less flexible, but preferred in my opinion given the k8s (k/k) versioning.

[nikhita]

If I import one package, the expectation is that it imports the correct version of all its dependencies.

Yes, this is the intention.

if someone starts doing v15/ imports it means they have to update their imports on a much higher rate because this v15 maps to a MINOR behind the lines that updates every 3 months.

This is true, such is the curse of versioned imports and a faster release cycle. :)

Experimenting in kubernetes/publishing-bot#196 to figure out how disruptive versioned imports could be.

versioned imports have the benefits of mixing APIs and code from different MAJORs, but do we have use cases for that outside of core (v1)?

Honestly, I'm not sure how useful combining different major versions will be for our repos since a bunch of them use global variables and things can quickly get 🔥 with them. I think the biggest benefit will be to seamlessly work with go modules.

Having said that, we will publish two tags for each tag of k/k - one with versioned imports and one without them.

[dims]

@liggitt @sttts WDYT?

[nikhita]

xref kubernetes/client-go#631

[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

[dims]

/area code-organization

[dims]

/remove-lifecycle stale

[k8s-ci-robot]

@nikhita: The label(s) area/release-infra cannot be applied. These labels are supported: api-review, community/discussion, community/maintenance, community/question, cuj/build-train-deploy, cuj/multi-user, platform/aws, platform/azure, platform/gcp, platform/minikube, platform/other

In response to this:

Published staging repos like kubernetes/api, etc have tags like kubernetes-1.13.1 which correspond to the v1.13.1 tag in kubernetes/kubernetes. Due to the kubernetes- prefix, tools like dep don't pick up the new version.

We could start using semantic versioning for tags in published repos as well. One way to do that (as pointed by @sttts on slack) is to have the tags as 13.0.1. This is also a faithful representation of our compatibility guarantees.

This would require a change to the publishing-bot.

/sig api-machinery
/sig release
/area release-infra
/cc @sttts @pohly @lavalamp @deads2k @liggitt

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.

[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]

/remove-lifecycle stale

[nikhita]

/priority important-longterm

[justaugustus]

@nikhita -- Is this still relevant?

[xmudrii]

Currently, there are no plans for implementing this. It has been decided to leave the issue open to avoid duplicates. Ref: https://kubernetes.slack.com/archives/CJH2GBF7Y/p1600779436038700?thread_ts=1600768354.032500&cid=CJH2GBF7Y

[pohly]

I vaguely remember a plan (or at least the intention) to ensure that different tags really reference different commits. Do I remember correctly and is that still planned even if the bigger changes around semantic versioning don't get implemented?

Right now it can happen that v0.20.0 and v0.21.0-beta.1 (or so - I'm making this specific example up) reference the same commit if nothing in the code changed. This becomes confusing during code review because then go get foo@v0.20.0 records foo as being imported from v0.21.0-beta.1 in go.mod.

[justaugustus]

@kubernetes/publishing-bot-reviewers -- is this still something we'd like to pursue?