Skip to content
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

Merged
merged 1 commit into from
Dec 23, 2021

Conversation

davidwessman
Copy link

  • 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.
@davidwessman
Copy link
Author

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')

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

Copy link
Author

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.

Copy link
Collaborator

@MoskitoHero MoskitoHero left a 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.

@MoskitoHero MoskitoHero merged commit 3d3ff4e into svenfuchs:master Dec 23, 2021
@f6p
Copy link
Contributor

f6p commented Dec 23, 2021

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.

@uxxman
Copy link

uxxman commented Dec 23, 2021

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

@f6p
Copy link
Contributor

f6p commented Dec 23, 2021

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

@uxxman
Copy link

uxxman commented Dec 23, 2021

@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
MINOR 0.x.0 level changes for any backwards compatible API changes, such as new functionality/features
MAJOR x.0.0 level changes for backwards incompatible API changes, such as changes that will break existing users code if they update

So, ideally this should have been 6.1.0

@MoskitoHero
Copy link
Collaborator

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.

@davidwessman davidwessman deleted the rails-7-david branch December 25, 2021 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants