search

vatesfr / terraform-provider-xenorchestra

Xen Orchestra provider for Terraform
MIT License
149 stars 33 forks source link

Could the provider adhere to the semantic versioning standards? #319

Open hkraal opened 2 months ago

hkraal commented 2 months ago

After renovate upgraded the xenorchestra provider from 0.24.2 -> 0.26.1 I noticed that there was a breaking change introduced on the xenorchestra_network resource by https://github.com/vatesfr/terraform-provider-xenorchestra/pull/260 (thanks for the fix btw, lost track of it, sorry for that).

While it's easy to fix it would be very nice if breaking changes would introduce a new major version so minor/patch level updates can be installed with relative safety.

ddelnano commented 2 months ago

Hi @hkraal, thanks for being active in providing feedback.

Unfortunately, I think there are some potentially large breaking changes that could come (#211 being one that will likely be disruptive, but worth addressing). This is why I've been sticking to a 0.x.y release number, which I'm indicating that a breaking change could come at any time. I have taken special care to keep backwards compatibility in mind (#267, #300), but there are still some rough edges in the current functionality that can only be solved by a breaking change.

Looking at the semver spec, it seems the area before 1.0 is a bit of a gray area. However, it does mention that 1.0.0 defines the public API and matches my hesitation for moving past a 0.x.y release.

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

... later in the FAQ

How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

hkraal commented 2 months ago

Let me start with the fact that you do follow SemVer and I was jumping the gun here, sorry for causing noise wrongfully.

I do understand your reasoning to stick to a 0.x.y release state as a developer but from a user perspective it would be very nice to know when things are expected to break. It's there but the release notes weren't very clear about this either but I certainly could have been more wary about the provider version <1.0.0 and thus not being crystallised out yet ;)

With all buzz around VMware and Vates it's clear intentions towards harbouring those which have been ditched by the Broadcom takeover; shielding the new users from breaking changes in minor releases might be worth something as well despite being valid in the 0.x.y release cycle