Semantic Versioning #9979

shaicoleman opened this Issue Mar 28, 2013 · 6 comments


None yet

6 participants


For Rails 4.0 and beyond, could we please follow the semantic versioning as per

This will also set a convention for all the gems and the rest of the ecosystem.

From a security point of view, semantic versioning is critical. If people don't know what an update entails, and how it will break their app, it means more insecure apps in the wild.



Also, this is the kind of thing for the rails-core mailing list, not Issues, which are for bugs only.

@tfausak tfausak referenced this issue in orgsync/active_interaction Jul 13, 2013
@AaronLasseigne AaronLasseigne fix #28 by correcting gemspec dependencies 7fe8f6f

Great answer @steveklabnik! Except it's not - why is this an automatic, definitive "No."?


Because we already follow a shifted version of semver.


Z - only bug fixes, no API changes.
Y - new features, may contains API changes.
X - new features, will contains API changes. Just bumped in special occasions


So the minor version number changing means both new features and breaking changes?

robin850 commented Mar 3, 2015

@billinghamj : Not exactly regarding breaking changes ; when the Y is incremented there may be features that are deprecated but they are still available but when it's incremented again, these features may not be there anymore (e.g. Numeric#ago was available in 4.0, deprecated in 4.1 and removed in 4.2).


As per the semver standard, that would be considered breaking. As you couldn't safely use a version dependency of '~> 4.0'. But yes, I understand Rails' versioning policy is different.

Thanks for the info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment