Curious:
1. How would you define "breaking changes" and "fixes"?
2. Can a library have its own interpolation of "breaking change"?
3. Would "the percentage of users affected" changes a "fix" to "breaking change", or vice versa? If so, why and what’s the threshold?
1. How would you define "breaking changes" and "fixes"?
2. Can a library have its own interpolation of "breaking change"?
3. Would "the percentage of users affected" changes a "fix" to "breaking change", or vice versa? If so, why and what’s the threshold?
Comments
2/ no. however, you can be fine with annoying users on your own terms and communicate it upfront
3/ no. however, you might care less or more based on that!
So maybe the breaking change definition itself needs to be part of the public interface.
*runs away*
https://www.semver-ts.org/
No project can test against *all apps using it* so we can:
1. Treat all incoming breaking change reports as bugs
2. Set expectations that we do the best we can without being backwards compatible
Instead of thinking about breaking or nor, think about the semantics you provide as a library or API, if the semantics change then it warrants a major release aka. breaking
2. No
3. No
2. Maybe? If you can, I would ask your "top" users and try to understand what they consider to be important according to them.
3. % of users shd nt make a change breaking
https://blog.isquaredsoftware.com/2024/11/presentations-maintaining-community/
- a bugfix _could_ break someone's code. To me it's a question of "what did we _intend_ this code to do?"
- yes, absolutely
- _strictly_ speaking any break is a major... but usage % does influence this too
undocumented behaviour changes could conceivably be breaking fixes …
we’re just both Right
This is sadly all too untrue out in the real world. We can get pedantic and agree that documenting LITERALLY nothing is probably rare, but doc amount and users count is not at all correlated, IME.
Here’s my definition that I think caused @antfu.me to post his question: https://github.com/eslint-stylistic/eslint-stylistic/issues/633#issuecomment-2528556497
If someone's existing code base could now break because of something you changed, that's a breaking change! Docs updates are a good *sign*, but.. I've seen ppl's docs...
2) Yes, and it's totally acceptable
3) yes and the threshold is whether you documented or suggested a workaround to the "bug". If so, that's a breaking change.
2. as long as it respects point one
3. no, because of point one
If the behavior isn’t documented yet, it initially will be in the changelog or migration guide.
All expectations can be broken, so you need some sort of “contract” of what those are to break.
If it’s reasonable for people to expect the current behavior and many rely on it, then it’s indirectly “documented” as such even if it isn’t explicitly documented as such.
Also: What constitutes “documentation”? Types? README?
React-Redux <=v5 used legacy React context to pass the store. never documented, not part of our public API. Frequently accessed by users despite that. We did change in a major, so fine by semver... but point is we considered it internal impl.
There's also no good way to do what the plugins need ("extension" rules).
https://github.com/eslint/eslint/issues/19173
If it’s reasonable for people to expect that current behavior _is the intended behavior_
I’m not referring to usage of internal API:s or to any monkey patching – purely referring to public API:s
3. % is a feeling unless you have statstics (very detailed ones)
2. I like to follow the North star+being abe to be flexible. No need specific "Def of breaking" (unless you are different)
1. I don't know, any one could leverage a bug, so fixes are always breaking changes ?
Let's be positive, any change as intent to improve things in a way. No ?
2. Sure! If you communicate that for example the folder /internal is not to be expected to be stable, it’s not a breaking change if that changes.
4b. intentional breaking changes should always ship with a new version, so the problem doesn't apply here
And here’s my definition in that thread: https://github.com/eslint-stylistic/eslint-stylistic/issues/633#issuecomment-2528556497
“I generally think that anything (fixes or features) that makes the default linting stricter or different is a breaking change unless it only affects rare edge cases (eg. <5% of users)”