Semantic Versioning #9979

Closed
shaicoleman opened this Issue Mar 28, 2013 · 6 comments

Projects

None yet

6 participants

@shaicoleman

For Rails 4.0 and beyond, could we please follow the semantic versioning as per
http://semver.org/

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.

@steveklabnik
Member

No.

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
@juniorplenty

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

@rafaelfranca
Member

Because we already follow a shifted version of semver.

X.Y.Z

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

@billinghamj

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

@robin850
Member
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).

@billinghamj

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