3 ms·

Major version bumps were never a problem. Semver-wise, the only conceivable problem is in introducing backwards-incompatible changes in minor or patch version b

Major version bumps were never a problem. Semver-wise, the only conceivable problem is in introducing backwards-incompatible changes in minor or patch version bumps. By bumping the major version, semver-wise it just means "be aware that your software might break if you upgrade blindly to this version." No one will die if you expect problems but end up having none.

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.

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.