Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New dotnet sdk versioning proposals #400

Closed
tg123 opened this issue Apr 4, 2020 · 2 comments
Closed

New dotnet sdk versioning proposals #400

tg123 opened this issue Apr 4, 2020 · 2 comments

Comments

@tg123
Copy link
Member

tg123 commented Apr 4, 2020

The problem

New version format should:

Proposals and solutions

draft some proposals for open discussion

Align with other client SDKs, Python, Java.

  • Update Major version for every single Minor kubernetes version.
  • Per Semantic Versioning, Major SDK update may introduce breaking changes

Java SDK solution https://github.com/kubernetes-client/java/blob/master/README.md#compatibility

|  client version  | 1.11      | 1.12     | 1.13     |  1.14     |  1.15    |
|------------------|-----------|----------|----------|-----------|----------|
|  3.0.0           |  ✓        |  -       |  -       | -         | -        |
|  4.0.0           |  +        |  ✓       |  -       | -         | -        |
|  5.0.0           |  +        |  +       |  ✓       | -         | -        |
|  6.0.1           |  +        |  +       |  +       | ✓         | -        |
|  7.0.0           |  +        |  +       |  +       | +         | ✓        |

Key: 

* `✓` Exactly the same features / API objects in both java-client and the Kubernetes
version.
* `+` java-client has features or api objects that may not be present in the
Kubernetes cluster, but everything they have in common will work.
* `-` The Kubernetes cluster has features the java-client library can't use
(additional API objects, etc).

Pack kubernetes version into SDK version

  • Like the solution above, the dotnet SDK version would be <Kubernetes Major>.<Kubernetes Minor>.<SDK updates>

such convention would help users understand better, but which doe

  • A workaround for issue above is to pack Major and Minor into one number, like <Kubernetes Major Kubernetes Minor (6 digits padding)>.<SDK update>.<SDK patch>

Docker image tag like Suffix

In additional to solutions above, also provide multiple branches build with suffix. (version with suffix will be treated as prerelease in nuget)

  • <Major>.<Minor>.<Patch> <- this one should be equal to last but without any suffix
  • <Major>.<Minor>.<Patch>-K1.14
  • <Major>.<Minor>.<Patch>-K1.15
  • <Major>.<Minor>.<Patch>-K1.16

Upgrade to new version format

Current version is 1.6.x, new version format should be Semantic Newer

@tg123
Copy link
Member Author

tg123 commented Apr 4, 2020

I, personally, prefer solution 2 + solution 3.
This is an open discussion, any comments are welcomed.

@brendandburns
Copy link
Contributor

Hrm, I think it's tricky, the trouble with encoding the Kubernetes version is that you either lose data (e.g. no opportunity for C# patch releases) or you end up with N different libraries (1.1.1-k1.14, 1.1.1-k1.15, etc)

That's why we went with the scheme that we use for the Java library.

I'm not 100% wedded to it, but it's what I would vote for (but I'm biased)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@tg123 @brendandburns and others