Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rails changed the meaning of NOT and nobody batted an eye - https://til.hashrocket.com/posts/3zyftipjiu-rails-will-chang...

These sorts of changes do in fact happen fairly frequently and developers need to be aware that they can't blindly accept upstream dependency changes.



That also is a really awful change and probably broke someone in production. Really there is no reason for the not function to take more than one argument. But if you have decided to overload the meaning to NAND, you'd better not later change it to NOR!


That is asinine. Why not change it in 5.x->6.0 if they knew it was a problem. Why even use version numbers at that point? Just use DateVer or 0ver at that point.


> Why not change it in 5.x->6.0 if they knew it was a problem

Because Rails explicitly has a versioning policy where minor versions are equivalent to SemVer major versions (but with deprecation notice in a previous minor version) and where major versions are also SemVer major with subjective significance distinctions; they call it “shifted SemVer”.

https://guides.rubyonrails.org/maintenance_policy.html

This is somewhat obnoxious, but not as bad as saying you use real SemVer and then brazenly breaking things in minor releases.


Sure, but like, you don't have to break code on .Y changes.

Changing semantics of a query operator is something worth saving for a "big major" update, if you change it all.

Some breaking changes are really obvious and easy to catch. Others can introduce pernicious bugs which slip through tests. The change Mongoid is solidly the latter. And yeah, they say they use actual Semver.


> Changing semantics of a query operator is something worth saving for a "big major" update, if you change it

Arguably, it was so important that they did a big major update just to deprecate it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: