v1alpha2 cut release

[ffromani]

we merged all the relevant PRs (#29 #28 #26 #25) and testbed PRs are looking good (k8stopologyawareschedwg/resource-topology-exporter#157 kubernetes-sigs/scheduler-plugins#488)
so we can cut a release.

The only thing left is to review the k8s standard recommendations to learn if the new tag should be 0.1.0 or 0.0.14

[ffromani]

/cc @swatisehgal

[fmuyassarov]

That would be good to have.

[fmuyassarov]

@ffromani when do you expect to add v1beta1 API? If very soon, would it make sense to hold the release until then ?

[ffromani]

v1beta1 work is at early planning stage and I don't think is helpful to hold the release until then. Unless there are clear reasons to change course, I prefer a "release early, release often" approach and many gradual improvements over a "let's change the world in one go" approach.

[swatisehgal]

we merged all the relevant PRs (#29 #28 #26 #25) and testbed PRs are looking good (k8stopologyawareschedwg/resource-topology-exporter#157 kubernetes-sigs/scheduler-plugins#488) so we can cut a release.

The only thing left is to review the k8s standard recommendations to learn if the new tag should be 0.1.0 or 0.0.14

I am in the favor of moving to 0.1.0 as that would allow us to provide a clear indication that 0.1.0 onwards corresponds to major a change (i.e. graduation of the the API to v1alpha2). Incrementing of the minor versions should correspond to minor changes.

I investigated a few projects that are not directly tied to Kubernetes release cycle e.g. projects under https://github.com/kubernetes-sigs. I arrived to the conclusion that there is no common pattern between the projects that are not tied to Kubernetes releases and typically make a call autonomously on release cadence and release iteration structure.

If I were to go back in time, I would have probably cut a v0.1.0 release when we reached at a reasonable "stable" state
of v1alpha1. That would have allowed us to go to v0.2.0 now with the graduation of API to v1alpha2 version. But, let's do the best we can now :)

v1beta1 work is at early planning stage and I don't think is helpful to hold the release until then. Unless there are clear reasons to change course, I prefer a "release early, release often" approach and many gradual improvements over a "let's change the world in one go" approach.

I agree. It is time to cut release and recognize this point in the API as a milestone!

[ffromani]

@swatisehgal thanks for checking! I'm also in favor of tagging 0.1.0. Fully agree to all your musings.

[ffromani]

done! https://github.com/k8stopologyawareschedwg/noderesourcetopology-api/releases/tag/v0.1.0