Update release policy

[Miouge1]

What type of PR is this?
/kind documentation

What this PR does / why we need it:
Adding info about kube_version_min_required and checksums.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Miouge1

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Miouge1]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mattymo]

+1 from me. Waiting for others to review

[LuckySB]

+1
I support if the practice of removing version hashes only after eol - is accepted.

And I understand that this is more likely a gentleman's agreement ;)
and in this document it should not be indicated

[EppO]

• Minor releases can change components' versions, but not the major kube_version.

If I understand correctly, it means that kubespray will only support Kubernetes 1.17 in 3.x?

[Miouge1]

@EppO Line 21/22 it says Fixes for major releases (vX.Y), therefore Kubespray v2.13 is the next major release, and it will support only v1.17.

It can be a little confusing if you are used to semver.

[huxcrux]

Looks good 👍

[chadswen]

+1, seems sensible and clear.

Related sidenote, I can start a new issue if there's interest: I once had an idea to support incremental kubernetes version upgrades automatically from upgrade-cluster.yml (e.g. when upgrading a kube_version: v1.13 cluster to v1.15 the playbook handles the required v1.14 upgrade for the user before applying the v1.15 upgrade). Slack thread

However, we should only consider that if the community thinks the convenience of running the upgrade playbook just once to upgrade across multiple k8s feature releases is worth the added complexity and effort. Otherwise, this current approach works quite well.

[Atoms]

/lgtm