Replies: 8 comments 5 replies
-
Coming from compiled languages: major.minor.patch;
|
Beta Was this translation helpful? Give feedback.
-
As a consumer I consider anything a breaking change that will break my application. IMO behavioral changes are worse than exceptions because they are silent and may impact application in ways that are critical but completely silent. Users could go days or weeks without noticing that their systems are misbehaving. For this reason, I always lock exact versions of my deps and always have reproducible builds. Any random person publishing code somewhere unrelated to my project should never result in my build changing in any way. IMO auto minor/patch version updates are highly overrated and cause a lot more pain than they solve. I wish we could enforce use of lock files and exact dep versions for our users :( As an OpenTelemetry author, I think if we make any changes that break collection or generation of telemetry data in any way, it should be considered a breaking change. If a change breaks relation between spans by breaking context propagation for example without breaking APIs, I think it should be a breaking change. I totally see your point of this being harder to define but I think as a SIG we are capable of making judgement calls for such rare cases instead of ignoring an entire set of cases that may break telemetry in customer apps on a simple re-deploy or seemingly innocent dependency upgrade. May be an infinitely expressive type system might have helped we don't have that :) |
Beta Was this translation helpful? Give feedback.
-
Here is more information. |
Beta Was this translation helpful? Give feedback.
-
Here's the spec doc around backwards compatibility: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md |
Beta Was this translation helpful? Give feedback.
-
Okay let's scope this issue down to specifically just "are changes in behavior breaking changes"? We have all already agreed that we must maintain semver and making changes/removal of API needs to increase in major version.
@ocelotl Brings up a good point here, and a specific instance can be seen in this pr. This change supposedly fixes an issue where the IMO, there will always be bugs and undefined behavior that users will find that we won't be able to catch right away. What we should promise users is that they should only take dependencies on behavior/components that are documented in our API surface. If they take a dependency on a "bug", we should not need to promise them that these will not break. One could argue "well what is a bug and what is a breaking behavior change"? This is why these cases will probably require some judgement on our part as a community. So our official message should be "users should not take dependencies on functionality and behavior that is not documented in our public APIs, but if they do, we do not have a promise that there will be stability guarantees. With that being said, we should make the experience and transition as smooth as possible for customers. If we are fixing major bugs that causes behavior changes, we should do our best to be as transparent as possible, to allow users time to upgrade and adjust to the change. This is an important issue to flesh out before our 1.0.0 so please comment on this if you have thoughts. |
Beta Was this translation helpful? Give feedback.
-
I agree. Also, from a users perspective, if I take a dependency on a library, I expect it to work and not break my apps (with or without crashes) months or years from now. If updating breaks my apps by introducing exceptions or behavioral change that fundamentally alter how the library functions or the data it produces then I'd consider that a breaking change. |
Beta Was this translation helpful? Give feedback.
-
I consider that for practical reasons it may not be convenient to stick to the very strict and limited definition of breaking changes that I suggested. In my opinion, the ideal scenario would be to be able to guarantee the user "you application code won't break when you use a version whose major number is the same as the one you have been using". This is also impossible to do, in my opinion, because application code is outside our control. What I consider critical from what @lzchen suggests is to only increase the major version number for a behavioral change when the behavioral change makes us introduce a change in documentation. I understand that documentation is in itself a commitment to our users, not as strictly defined as an API but a commitment still. |
Beta Was this translation helpful? Give feedback.
-
One really important use case to remember is library authors who instrument their library directly with E.g. |
Beta Was this translation helpful? Give feedback.
-
In the last SIG we raised this philosophical question, what does backward compatibility mean?
SemVer says this:
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.
Since it mentions "the public API", in my opinion, this means that the major version MUST be increased if we do something like removing a public class, or changing the signature of a public method.
I think defining backwards incompatibility in this way has the advantage of being deterministic, there is a clear, limited definition of what a backwards incompatible public API change means, a removal of a public API symbol or the change of a function signature (maybe this definition includes something else I am not considering right now).
This being said, other folks have a different opinion. From what I understood in the SIG (please correct me if I am wrong), they consider a backwards incompatible change some change that can cause application code to break, even if it does not change the public API itself. This definition of a backwards incompatible change includes changes in the code behavior.
I understand how this definition is convenient for the end user, if a change in the behavior some OpenTelemetry Python component can break application code, increasing the major version number is a good way of letting the user know that, which is the same thing we do for public API changes, we let the user know their application code may break.
What I find a bit inconvenient with this definition is that we would be using code behavior as criteria and code behavior is less well defined and less deterministic. In theory, any bug fix can be considered a change in behavior and can cause application code to break, right?
I imagine this problem has happened before to other Python developers, so maybe if we take a look at the release history of some Pyhton packages we can get some inspiration to solve our problem as well? 🤷♂️
Anyways, please leave your comments below 😄
Beta Was this translation helpful? Give feedback.
All reactions