3 ms·
> make a breaking change to the gem versioning system to force all library, framework and gem authors to use versions properly. I really like the RubyGems rati
by techiferous 15y ago
> make a breaking change to the gem versioning system to force all library, framework and gem authors to use versions properly.
I really like the RubyGems rational versioning policy ( http://docs.rubygems.org/read/chapter/7 http://docs.rubygems.org/read/chapter/7 ) and wish everyone followed that.
I think it might be harder for gems like Rails that are actually metagems. But I do agree that it's surprising for a move from 2.3.5 to 2.3.6 to break backwards compatibility. Have we forgotten Ruby's ideal of the principle of least surprise?
Perhaps a good compromise between what Rails is currently doing and what it should be doing is to add a fourth version number. When the fourth version number changes, you can rest assured that the change is backwards compatible. (However, there is always the danger that some plugin/engine/gem author monkey-patched a part of Rails which could make their code break during a "backwards-compatible" upgrade to Rails.)
- bryanlarsen 15y agoI was probably being a little bit too harsh: the 2.3.5 to 2.3.6/2.3.7 changes were not intentionally breaking, but given that they added a major new feature (XSS support), it's not surprising. (2.3.6 was completely busted, but 2.3.7 released a day after 2.3.6 still contained breaking API changes for us) I like the 4th version number idea. Since everybody in the Ruby community seems to think that it's okay for major breaking changes to occur on a minor version bump, let's adjust policy to match practice rather than the other way around. Let's call the first number the "political" number, the second the "major", the third "minor" and fourth "patch".
- techiferous 15y ago> Since everybody in the Ruby community seems to think that it's okay for major breaking changes to occur on a minor version bump I would say this is true for Rails, but I think (or hope!) there is a consensus (or at least a majority opinion?) among Ruby developers that any gem version that breaks compatibility should change the major (1st) version number. Otherwise, the ~> operator used by bundler and RubyGems becomes meaningless. All of the gems that I publish strictly follow the rule that any change that could break code will bump the 1st version number, any change that adds features/behavior will bump the 2nd version number, and any change that has no interface effect (bug fixes, performance enhancements, documentation tweaks) will bump the 3rd version number.
- bryanlarsen 15y agoI hope you're right. But luckily ~> isn't completely broken. In my rails apps I use ~> x.y.z to ensure that I only pull in patch level changes.