-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Update for Rails7 - but support Rails 6 #962
Conversation
davidwessman
commented
Dec 23, 2021
- Allow runtime railties 7.0.0 dependency.
- Bump version number to 7.0.0.
- Update Gemfile.lock.
- Kept @f6p as author but fixed the comments.
- Allow runtime railties 7.0.0 dependency. - Bump version number to 7.0.0. - Update Gemfile.lock.
I made a new version of #957 which allows Rails 6 as well. |
@@ -16,7 +16,7 @@ Gem::Specification.new do |s| | |||
s.required_rubygems_version = '>= 1.8.11' | |||
|
|||
s.add_runtime_dependency('i18n', '>= 0.7', '< 2') | |||
s.add_runtime_dependency('railties', '>= 6.0.0', '< 7') | |||
s.add_runtime_dependency('railties', '>= 6.0.0', '< 8') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to assert an incompatibility with a version that does not even exist? End users are entirely capable of pinning and making these decisions themselves.
It is a PITA when gems do this because every two years we have to this same exact dance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the reasoning is that we do not understand what will change in Rails in the future. Then I think it is better that the gem authors can decide: "This is now supported by Rails 8", instead of all the users updating automatically and then get mad when it does not work.
But when it is not maintained actively it is a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me.
Guys I'm not an expert on a matter but there is probably a good reason why every major release of rails-i18n since rails3 locked to rails version of railties. Besides that there is a little point in supporting both 6 and 7 at the same time as there is already gem for 6 and 7 requires new release anyway... Also #958 needs to be merged before bumping gems/versions otherwise syntax errors will be thrown. |
@f6p PR #958 is a good example why supporting most (6 and 7 both) versions is beneficial, otherwise every minor/major fix/improvement needs to be back ported to v6 for people using rails 6 and keep going back. When we support both, people using rails 6 and rails 7 both can install the latest rails-i18n that is up-to-date with all fixes and new additions. |
@uxxman but what if one version will introduce breaking changes? then one repository that patches everything needs to be mantained. that also has a price. |
@f6p that's what semantic versioning is for. https://guides.rubygems.org/patterns/#semantic-versioning PATCH 0.0.x level changes for implementation level detail changes, such as small bug fixes So, ideally this should have been 6.1.0 |
Hello guys, I have just started maintaining this gem along with @pama. I believe semver is the way we should version this gem from now on. There are a few improvements that need to be made here and there and we both need a little time to get started (winter holiday season) so bear with us as we gradually agree on how we will manage this. For now I am just going to merge important requests (rails 7 compatibility and bugfixes like #958) that prevent the community from moving forward. |