search

k8stopologyawareschedwg / noderesourcetopology-api

This repository contains an implementation for CRD (https://docs.google.com/document/d/12kj3fK8boNuPNqob6F_pPU9ZTaNEnPGaXEooW1Cilwg/edit)
Apache License 2.0
8 stars 6 forks source link

v1alpha2 cut release #30

Closed ffromani closed 1 year ago

ffromani commented 1 year ago

we merged all the relevant PRs (https://github.com/k8stopologyawareschedwg/noderesourcetopology-api/pull/29 https://github.com/k8stopologyawareschedwg/noderesourcetopology-api/pull/28 https://github.com/k8stopologyawareschedwg/noderesourcetopology-api/pull/26 https://github.com/k8stopologyawareschedwg/noderesourcetopology-api/pull/25) and testbed PRs are looking good (https://github.com/k8stopologyawareschedwg/resource-topology-exporter/pull/157 https://github.com/kubernetes-sigs/scheduler-plugins/pull/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 commented 1 year ago

/cc @swatisehgal

fmuyassarov commented 1 year ago

That would be good to have.

fmuyassarov commented 1 year ago

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

ffromani commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

ffromani commented 1 year ago

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