New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantic Versioning #9979

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

Comments

Projects
None yet
6 participants
@shaicoleman

shaicoleman commented Mar 28, 2013

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

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Mar 28, 2013

Member

No.

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

Member

steveklabnik commented Mar 28, 2013

No.

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

tfausak referenced this issue in AaronLasseigne/active_interaction Jul 13, 2013

@juniorplenty

This comment has been minimized.

Show comment
Hide comment
@juniorplenty

juniorplenty May 29, 2014

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

juniorplenty commented May 29, 2014

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

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca May 29, 2014

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

Member

rafaelfranca commented May 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@billinghamj

billinghamj Mar 3, 2015

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

billinghamj commented Mar 3, 2015

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

@robin850

This comment has been minimized.

Show comment
Hide comment
@robin850

robin850 Mar 3, 2015

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@billinghamj

billinghamj Mar 3, 2015

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.

billinghamj commented Mar 3, 2015

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