-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semantic versioning proposal #842
Comments
@et1975 Yes, we should probably do something like that. Up until now we've been fairly lax on versioning with regards to the API except for two things:
|
Hey I've thinking about this, maybe it's too much, since it touches on a lot of stuff. The ARM templates follow a spec that is versioned, this is currently not represented in the API or package version. Updating the resource type version to support new features seems like a hard decision to make, since it might have unintended consequences, as Farmer is technically targeting a different Azure API, which might behave differently regardless of changes in the JSON. The strictness in changing the ARM output might not be very helpful, since it sets incentives to keep outdated implementations, that might not even work anymore. What if the builders were versioned according to the spec? Like instead of While this isn't really about semantic versioning, it could help to reduce breakages. I'm not sure how to structure the builders internally for this, this could either mean a bunch of duplication in the code base or some major changes internally. I've been toying with the idea of computation expression builders (like builder builders?) to keep the API (mostly?) stable and reduce duplication while enabling these versioned builders. Idk if a lib like it already exists to enable this, but it would be nice if you could be more explicit about the resource version you're targeting. Exactly because things might not work as expected sometimes and you'd need to target a specific one sometimes. The idea is kind of inspired by how applicative form builders work, not exactly like Fable.Form, but somewhat like it. So you'd reuse/reference field definitions from previous versions and compose them together into a CE, that looks like the one we have today. I'm not sure if it's possible to build usable CEs at runtime though, so this approach might be a flop. Versioned builders would be neat though imo. |
I may have misinterpreted the OP, but I believe this issue is about breakage in Farmer rather than API changes in ARM. It's frustrating to when code breaks just because of a package update. Usually the builders can be made backwards compatible. This is probably one of my biggest revisions I request when reviewing. Breakage more often comes from complex parameter types that don't use a builder, which means that adding a field to a record will break anyone using it. We really can't guarantee any backwards compatibility on the resource records that the builders are creating. This should be considered a public but not stable API. For the ARM API versions, those can nearly always increment without any issue, so long as there is no structural change. It is up to the the resource providers to ensure this, but the ARM team also heavily gates breaking changes. A new ARM API version in and of itself does not change anything at all on the underlying resource. It may expose more options, but the underlying resource would be the same. If we look hard enough, we can find exceptions (ACI subnets is a recent one), but they are rare enough to take on a case by case basis rather. |
I was referring to Farmer DSL changes - adding/removing a required param, changing the type used in the DSL in breaking manner, CE keyword renames, etc. My thinking was as we find better abstractions the breakages are unavoidable. The breakage happening as result of changing to a new resource provider version are interesting too, but seem different. |
It definitely adds a lot of complexity to be able to emit different versions based on features, probably an unsustainable amount. Here's an example where I did this for container groups due to their breakage, and this is difficult to test and maintain. I did that because it was a unique exception, and while it's not elegant, even something cleaner would lead to a huge and tedious testing process to test the ARM resources emitted for different API versions. |
I often find the API has been broken within the same major version.
Would it make sense to start using semantic versioning to give the user indication - "broken API ahead"?
The text was updated successfully, but these errors were encountered: