3 ms·

> This type of library API breaking change on a minor version update basically never happens. Literally happens all the time with Rails. To the point they deci

> This type of library API breaking change on a minor version update basically never happens. Literally happens all the time with Rails. To the point they decided to call their versioning schema “shifted semver” to afford themselves API changes on minor versions: https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html Good luck if you are using Rails and ecosystem and you expect any sort of sensible versioning.

chucke 5y ago
Rails never was semver. Their yearly major-minor grand release always, always breaks API all around. It's inevitable. Any rails-only gem will as a result have a strong incentive not to follow several.
byroot 5y ago
Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails must first emit deprecation warnings, so unless you are jumping one version, this kind of scenario shouldn't happen with Rails itself. Also note that Ruby (MRI) itself more or less behave the same regarding versioning, deprecations and breaking changes. First emit warnings, then break.
- astrowilson 5y ago
  That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is. The language and framework, by your own statement, are pushing breaking changes at a yearly rate. That’s a horrible developer experience.
  - byroot 5y ago
    No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite sized yearly changes to much bigger changes over longer periods. e.g. Ruby with this strategy never had the big divide Python 3 had with its much larger change.
    - astrowilson 5y ago
      You may not believe this, but there are other ways of versioning software beyond breaking things every year and doing whatever Python 3 did.
      - byroot 5y ago
        > You may not believe this You may not need to be confrontational... > there are other ways of versioning software I'm sure there is. But some features and other improvements sometimes require to deprecate and remove some older features. Each project will chose its own tradeoff between bringing the improvement faster vs keeping compatibility longer.
- flubflub 5y ago
  I don't use Ruby. Are packages that don't follow semver allowed to be released? Haskell asks for PVP for example.
  - byroot 5y ago
    Yes, you'd need an automated way to catch the API breakage, which would be particularly tricky. And even with very strict typing, the breaking change showcased in the article wouldn't have been caught, the API stayed the same, it just behave differently. Not every backward incompatible change is as simple as a function signature change.
    - flubflub 5y ago
      When I tried to submit a package to Hackage, I was asked if I was aware of the packaging guidelines. The person who I emailed to register also inspected my package and told me that my dependencies were wrong and not compliant. I really don't think this is a scalable approach and was really surprised that someone took the time to check my dependencies personally. My experience may just be rare. I meant more on the human side than automated. Haskell doesn't have that much to do with formal verification in usual use. I'm not sure what the best policy for a good yet vibrant package ecosystem is.

chucke 5y ago

Rails never was semver. Their yearly major-minor grand release always, always breaks API all around. It's inevitable. Any rails-only gem will as a result have a strong incentive not to follow several.

byroot 5y ago

Rails committer here. First I get that people are used to SemVer, but it is unreasonable to assume all projects follow it. And yes in semver terms, you can simply assume that Rails X.Y is a major release. Then, any breaking change in Rails must first emit deprecation warnings, so unless you are jumping one version, this kind of scenario shouldn't happen with Rails itself. Also note that Ruby (MRI) itself more or less behave the same regarding versioning, deprecations and breaking changes. First emit warnings, then break.

astrowilson 5y ago
That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is. The language and framework, by your own statement, are pushing breaking changes at a yearly rate. That’s a horrible developer experience.
- byroot 5y ago
  No the expectation is that users of projects stop assuming SemVer is followed by every projects. > pushing breaking changes at a yearly rate. That’s a horrible developer experience. That's your opinion. I much prefer these bite sized yearly changes to much bigger changes over longer periods. e.g. Ruby with this strategy never had the big divide Python 3 had with its much larger change.
  - astrowilson 5y ago
    You may not believe this, but there are other ways of versioning software beyond breaking things every year and doing whatever Python 3 did.
    - byroot 5y ago
      > You may not believe this You may not need to be confrontational... > there are other ways of versioning software I'm sure there is. But some features and other improvements sometimes require to deprecate and remove some older features. Each project will chose its own tradeoff between bringing the improvement faster vs keeping compatibility longer.
flubflub 5y ago
I don't use Ruby. Are packages that don't follow semver allowed to be released? Haskell asks for PVP for example.
- byroot 5y ago
  Yes, you'd need an automated way to catch the API breakage, which would be particularly tricky. And even with very strict typing, the breaking change showcased in the article wouldn't have been caught, the API stayed the same, it just behave differently. Not every backward incompatible change is as simple as a function signature change.
  - flubflub 5y ago
    When I tried to submit a package to Hackage, I was asked if I was aware of the packaging guidelines. The person who I emailed to register also inspected my package and told me that my dependencies were wrong and not compliant. I really don't think this is a scalable approach and was really surprised that someone took the time to check my dependencies personally. My experience may just be rare. I meant more on the human side than automated. Haskell doesn't have that much to do with formal verification in usual use. I'm not sure what the best policy for a good yet vibrant package ecosystem is.