Update versioning support

[spzala]

This PR updates versioning support per the discussion under etcd
issue - etcd-io/etcd#13912

Signed-off-by: Sahdev Zala spzala@us.ibm.com

[spzala]

cc @ahrtr @serathius @ptabor

[ahrtr]

Thanks @spzala for clearly clarifying this in our official doc.

Usually a project needs to support three latest versions, so does K8s and etcd. But etcd doesn't keep the release promise just as the issue etcd-io/etcd#13912 pointed out. Personally I agree the proposal of only supporting two versions (such as 3.5 and 3.4 for now), reasons & points:

1. With limited active maintainers, we have no resource to support three versions for now;
2. All active Kubernetes versions are using etcd 3.5. Of course, the public managed K8s platforms (such as EKS, GKE, etc.) are still running K8s 1.21/etcd 3.4. But no any K8s platform is using etcd 3.3, so It's safe to give up etcd 3.3.
3. Before we release etcd 3.6, we really need to stabilize etcd 3.5 so that all of us (including all contributors and users) have enough confidence to completely migrating to 3.5. So there is no rush to release 3.6.
4. If anybody doesn't agree with the proposal, then we can revisit the proposal when we release etcd 3.7. It means the proposal should be good enough before we release etcd 3.7. The reason is that both etcd 3.3 and 3.4 are out of support for a long time, of course 3.4 is much better after we release 3.4.19 and 3.4.20 (coming soon); so we really want all use cases converge to 3.5 as soon as possible.

[ahrtr]

LGTM

[spzala]

@ahrtr thanks for the added context. It will be helpful for anyone referencing this PR. And yes, absolutely, we can revisit the proposal and current policy as per the future need and when we have increased bandwidth in the team.

[spzala]

Considering the discussion related to these changes were open for more than a month in the issue (as mentioned in the PR description), I am merging this PR to keep the versioning doc page latest.