drop v1alpha1

[BenTheElder]

we should not support alpha APIs indefinitely. we should get to at least a beta endstate quickly and drop support for alpha APIs, as such I'd kinda like to just support one API version ...

[luxas]

In kubeadm we've always supported two external versions at a time, and that's worked really well. So the user may read the older config in the newer binary, and conversion happens automatically internally.
e.g.
0.0.1 -- v1alpha1 (preferred)
0.1.0 -- v1alpha1 and v1alpha2 (preferred)
0.2.0 -- v1alpha2 and v1alpha3 (preferred)
0.3.0 -- v1alpha3 and v1beta1 (preferred)
etc.

[neolit123]

having learned from kubeadm and how k8s does its deprecation policies i'd say it's too early for beta of the api.

in a beta state each field that has to be removed has to be held in a deprecated state for 9 months or 3 releases:
https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api

i think it's on the safe side to hold the alpha state for as long as possible until we are confident about it.

[luxas]

Note that what we did for kubeadm was to essentially promise beta quality (you always have an upgrade path), where the spec itself changes in in-backwards-compatible ways (alpha).

[BenTheElder]

so FWIW these APIs are essentially 100% different, because the single -> multi node support changes.

I also think we shoot ourselves in the foot, so to speak, to go full blown deprecation policy when the tool is < 1.0. I'd like to get us to a supportable 1.0 / beta grade quickly, and I consider the entire released binary in 0.1 to be alpha with no real policies in place yet. Once we do a little more I'm fine hitting beta and keeping fields stable, as stability will be a core feature :-)

[BenTheElder]

there are also exceedingly low users for the v1alpha1 config, keeping it around risks that number increasing 😉

[tao12345666333]

I hope that we can continue to release the version.

And add some docs for describe the API version supported, like cri-tools's docs.

Current Status

Version matrix:

Kubernetes Version	cri-tools Version	cri-tools branch
1.13.X	v1.13.0	master
1.12.X	v1.12.0	release-1.12
1.11.X	v1.11.1	release-1.11
1.10.X	v1.0.0-beta.2	release-1.10
1.9.X	v1.0.0-alpha.1	release-1.9
1.8.X	v0.2	release-1.8
1.7.X	v0.1	release-1.7

Currently I recommend many Chinese developers to use kind and give them a guide.（you can find them by Star data）

The point that many people are confused about is why there is only version 0.0.1 now.

Now that kind has a certain degree of attention, we should keep a smooth upgrade.

Thanks.

[BenTheElder]

Thanks, we're trying to keep kind upgrades smooth, this particular one may be a bit bumpy because the first one was very early. I am indeed keeping the v1alpha1 in this release (currently building one!) but I think after we have a release with v1alpha2 we should maybe move on as the v1alpha1 config is missing too much functionality (cannot express multi node at all for one).

…

On Tue, Jan 15, 2019 at 7:17 PM Jintao Zhang ***@***.***> wrote: I hope that we can continue to release the version. And add some docs for describe the API version supported, like cri-tools <https://github.com/kubernetes-sigs/cri-tools#current-status>'s docs. Current Status Version matrix: Kubernetes Version cri-tools Version cri-tools branch 1.13.X v1.13.0 master 1.12.X v1.12.0 release-1.12 1.11.X v1.11.1 release-1.11 1.10.X v1.0.0-beta.2 release-1.10 1.9.X v1.0.0-alpha.1 release-1.9 1.8.X v0.2 release-1.8 1.7.X v0.1 release-1.7 Currently I recommend many Chinese developers to use kind and give them a guide.（you can find them by Star data <https://github.com/kubernetes-sigs/kind/stargazers>） The point that many people are confused about is why there is only version 0.0.1 now. Now that kind has a certain degree of attention, we should keep a smooth upgrade. Thanks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#219 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA4BqwHmRf4vg6u5HBLacfA8MG0rS6ABks5vDpmsgaJpZM4aANC4> .

[BenTheElder]

release will be #226, does contain v1alpha1

[tao12345666333]

Thanks. On 01/16/2019 12:20, Benjamin Elder wrote: release will be #226, does contain v1alpha1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[neolit123]

I also think we shoot ourselves in the foot, so to speak, to go full blown deprecation policy when the tool is < 1.0. I'd like to get us to a supportable 1.0 / beta grade quickly, and I consider the entire released binary in 0.1 to be alpha with no real policies in place yet. Once we do a little more I'm fine hitting beta and keeping fields stable, as stability will be a core feature :-)

in reality, 1.0 does not need to be beta even.

we should hold to alpha as much as possible, because a beta API means the API is stable, a subject to minor amends and ready for v1.

on the advertisement side (beta vs alpha), consumers nowadays are not scared to use pre-alpha state even. just look at the cluster-api - all big players have jumped that train.

Thanks, we're trying to keep kind upgrades smooth, this particular one may
be a bit bumpy because the first one was very early. I am indeed keeping
the v1alpha1 in this release (currently building one!) but I think after we
have a release with v1alpha2 we should maybe move on as the v1alpha1 config
is missing too much functionality (cannot express multi node at all for
one).

aren't we holding the release until multi-node is enabled on the UX side?
oh, i saw #226 now.

[neolit123]

after the meeting today.

we should not support alpha APIs indefinitely. we should get to at least a beta endstate quickly and drop support for alpha APIs, as such I'd kinda like to just support one API version ...

something else to consider about the quick drop of alpha and going beta is: multi-cluster and how do we want the config to look like. on the kubeadm side we don't really need this, but i though that there is generic interest for it.

like i've mentioned it seems quite scary to move that quick.
but we can try...

[neolit123]

/kind design

[BenTheElder]

If we can just avoid exploding kind's core scope and focus on provisioning local clusters with container nodes ... I think we can handle this. Multi-cluster looks like multi-config.

The single cluster config is in pretty good shape. I think we need to split out the non-k8s nodes (load balancer) so the fields don't have disjoint sub-fields, but otherwise I think it's in a fairly shippable state.

(also to calm you all down, the dirty secret is that i'm mostly using this as a forcing function to push us to think about and make breaking changes to the core format now so we can stop breaking people, getting the breakage done is the important part)

[neolit123]

i can take the task of removing the old config for 0.2.
one question: this leaves us with only support for v1alpha2 and no converters - are we OK with that?

[BenTheElder]

let's hold this until we get v1alpha3 (probably with host path and re thought loadbalancer / networking config ... hope to propose soon)

[neolit123]

ok!

[BenTheElder]

/lifecycle active
will happen with #340

[BenTheElder]

done in #373