5 ms·
Don't equate Rails with Ruby (some projects follow semver very closely). Rails follows a shifted semver version, as documented here: https://github.com/rails/r
by Argorak 12y ago
Don't equate Rails with Ruby (some projects follow semver very closely).
Rails follows a shifted semver version, as documented here: https://github.com/rails/rails/blob/master/guides/source/maintenance_policy.md https://github.com/rails/rails/blob/master/guides/source/mai...
Bumps from 4.x to 4.y might contain smaller breaking changes.
For a large project as Rails, I find that reasonable, otherwise, we'd be at Rails 20 by now, which also doesn't quite give a good sense of how the project evolved.
- bryanlarsen 12y agoRails, for better or worse, is the flagship project of Ruby, and shapes the Ruby culture quite strongly. I would much prefer Rails 20 than the current situation. If you want to make a major marketing level move, introduce a codename or something. Separate marketing from semantics.
- awj 12y agoMRI didn't follow semver up until recently, and even now it has some caveats about it. Ruby as an ecosystem doesn't really care for semver. Some projects follow it anyways, which I can respect, but they aren't the norm.
- matdes 12y agoMRI still doesn't follow semver but core doesn't really give a crap.
- steveklabnik 12y agoThey claim "Semantic Versioning type" versioning, which is, of course, not SemVer, but I think what your parent was referring to. https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/ https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-po...
- Argorak 12y agoMRI picked its version scheme in the 90s, long before "semver" was a thing. That kind of version scheme wasn't unusual in that time. Problems due to legacy don't make a good argument. The Ruby system cares for semver in general and it is propagated there a lot, but I agree: it certainly isn't uniform.