v3.2: makes the versioning and deprecation non-breaking for minor versions

[baywet]

motivation: having 3.1 being a minor version on paper but in reality bringing a lot of breaking changes caused confusion and friction for consumers, tools implementers etc...
This is partly due because nowadays, a lot of the industry is following, and expects others to follow semver.
This pull request updates the verbiage of the versioning and deprecation policies so it forbids making breaking changes in minor/patch versions, so we can conform to semver, after 3.1.

[lornajane]

I am not in favour of this change.

Additionally, I find it particularly unhelpful for it to be proposed at the end of a development cycle which has been worked on under different constraints. Hard no from me.

See also #2415

[baywet]

I am not in favour of this change.

@lornajane besides the reasons articulated in the linked issue, do you have additional reasons why you're against such a change?

Additionally, I find it particularly unhelpful for it to be proposed at the end of a development cycle which has been worked on under different constraints. Hard no from me.

What do you encompass as the development cycle here? 3.2? 3.X?

• In the case of 3.X, well, I wasn't here at the time :)
• In the case of 3.2, I've submitted this PR against that branch to start with, but if this ends up being accepted, I suggest we backport it to 3.1 as well.

[ralfhandl]

This section only expresses what the current TSC hopes a future TSC will or will not do. A future TSC can completely ignore and rephrase it. Making the text more restrictive doesn’t change this fact.

The current text reflects what past TSCs have done after serious deliberations, and I prefer to keep it as is to (a) honor the tough decision they made and (b) give the same freedom and responsibility to future TSCs.

[handrews]

That's two solid "no" votes from the TSC, so I'm going to close this.