3 ms·
Ok, but how do you know that a change (possibly a bugfix) in your code will break something (maybe a weird, broken thing) that I depend on? The language Unison
by escherize 6y ago
Ok, but how do you know that a change (possibly a bugfix) in your code will break something (maybe a weird, broken thing) that I depend on?
The language Unison has an elegant solution: hashing the ast as the version.
- rumanator 6y ago> Ok, but how do you know that a change (possibly a bugfix) in your code will break something (maybe a weird, broken thing) that I depend on? This isn't rocket science. Fix bug that doesn't change behavior nor the interface? Bump patch number. Add feature/extend interface? Bump minor version. Otherwise, bump major version. That's pretty much it. For a detailed definition: https://semver.org/spec/v1.0.0.html https://semver.org/spec/v1.0.0.html The point of semver is that it's a kind of contract where you implicitly summarize the nature of the changes you introduce in a release in its version number. You provide contextual hints through the version number.
- jakelazaroff 6y ago> Fix bug that doesn't change behavior nor the interface? Bump patch number. How would you fix a bug without changing behavior? “Incorrect behavior” is the definition of a bug.
- donmcronald 6y ago> Ok, but how do you know that a change (possibly a bugfix) in your code will break something (maybe a weird, broken thing) that I depend on? That would be unintentional though. If that happens to you report it as a regression and most developers will give it super high priority and even release a hotfix to deal with it. There's a big difference between accidental breakage, which is always a bug, and intentional breakage where it's reasonable to give some type of notice to people consuming your platform / API.