Release kube 1.0 #1688
Description
Reasoning
Optics
There are no major features we really need left to be classified as "1.0". We support basically everything.
(like, we don't have k8s-pb integration (not needed for 1.0) and not stream sharing (unstable), but we don't need to wait for those hard, non-essential features.)
At this point a 0.100.0 release feels like a bad optics issue that's sending a signal that we'll never 1.0.
Easier Upgrades
It's easier for cargo-upgrade/dependabot/renovate to get upgrades through for 1.0.0 -> 1.1.0 than 0.98.0 -> 0.99.0 because minors are not considered breaking post 1.0 so we can follow standard semver with feature adds without doing a "technically semver breaking" release every time.
Majors with k8s-openapi
We always need a bump a minor with k8s-openapi, and we always tell people to explicitly upgrade both at that point, so may as well do a major release every Kubernetes version. That has good optics to me (even if we end up with version 6 in like 2 years).
Less Movement
Lots of libs we rely on are 1.0, and uncertainty around hyper is much smaller now after it's 1.0 releases.
Of course there is stuff left to do, and lots of sub 1.0 deps. But it's not like couldn't be careful and do those before the k8s-openapi release. We basically do less than one release a month anyway.
Context
See also: