No tag for significant api changes

[pkliczewski]

Recently we bumped api version due to renaming of ovm to vm and vm' tovmi`. Please provide a way to from which commit we can use newer version.

[pkliczewski]

@lukas-bednar cc

[lukas-bednar]

I don't know how to deal with this properly. This code is auto-generated after every merge of PRs which committed changes into KubeVirt's OpenAPI specification. I guess we can push tag to this repository per each KubeVirt release, with same name ...

@rmohr do you have any suggestion ? I remember that we were discussing this in the past, but didn't come with conclusion.

[lukas-bednar]

Based on discussion at community meeting, we push tag on every kubevirt release. In addition we will create branches for release-0.4 & release-0.6 .

[pkliczewski]

We need to synchronize api changes with kubevirt so we can version the client.

[rmohr]

We need to synchronize api changes with kubevirt so we can version the client.

@pkliczewski yes, not sure if my comment is helpful but whenever kubevirt is released the kubevirt release-job can also do the tagging on the client-python repo. Should be pretty easy since we already push content to this repo on every build in kubevirt: https://github.com/kubevirt/kubevirt/blob/master/hack/gen-client-python/deploy.sh.

[pkliczewski]

@rmohr This should be good to start with. I noticed that sometimes when we update our dependencies like generators or k8s there are changes in api definition which we need to handle somehow. I have one additional remark that we do not need to update client's version if there were no changes on the api level.

I am thinking on using dynamic client which would remove a need to version anything.

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[pkliczewski]

No need for this issue anymore.