Update for Rails 8 #1130
Update for Rails 8 #1130
Conversation
rails-i18n.gemspec
Outdated
| s.add_dependency('i18n', '>= 0.7', '< 2') | ||
| s.add_dependency('railties', '>= 6.0.0', '< 8') | ||
| s.add_runtime_dependency('i18n', '>= 0.7', '< 2') | ||
| s.add_runtime_dependency('railties', '>= 6.0.0', '< 9') |
There was a problem hiding this comment.
Should there be an upper constraint at all?
There was a problem hiding this comment.
I don't think so; was trying to introduce the least amount of friction to get this approved.
If maintainers are okay with it I'd love to remove the upper constraint!
There was a problem hiding this comment.
Just remove it. Upper constraints are almost always a bad idea.
There was a problem hiding this comment.
Exactly. Unfortunately some maintainers still believe it's safer to restrain the upper limit. which leads me to maintain a lot of forks every year
There was a problem hiding this comment.
Thank you for removing this!!!
Schwad
force-pushed
the
schwad_rails_8
branch
from
007ee80
to
04b0df4
Compare
casperisfine
force-pushed
the
schwad_rails_8
branch
from
c0f1aa8
to
b679cb9
Compare
|
@sunny done. |
casperisfine
force-pushed
the
schwad_rails_8
branch
from
b679cb9
to
96778ff
Compare
|
I get the point about upper constraints and understand that it might create difficulties for maintainers looking to update their code to the latest Rails version. However, I want to ensure that the current release version aligns with the correct Rails I18n keys. I'm hesitant to drop the version constraint because we could run into issues with mismatched keys if we start using versions ahead of our release. It could also set a precedent for having to accept PRs with keys from previous versions, which I've been refusing. I know we don’t have changes often, but they do happen, like the introduction of |
|
I think having a minimum dependency is helpful. Rails 7 requires rails-i18n 7, Rails 8 requires rails-i18n 8, etc. That would solve @pama's issue? |
Well, restricting only the major doesn't make sense then, because Rails from a semver standpoint 7.2 is as much of a major as 8.0, and it just as likely to add a key. But you are the maintainer, so do what you prefer. If you want to keep the constraints, it's up to you. But either way, can this be solved soon please? Rails 8.0 is in RC1 and this is making it harder for people to test it. |
|
@pama if I reintroduce a constraint would it be possible to merge this please. |
Remove upper constraint as per svenfuchs/rails-i18n#1130 (comment)
Remove upper constraint as per svenfuchs/rails-i18n#1130 (comment)
Remove upper constraint as per svenfuchs/rails-i18n#1130 (comment)
|
Hey! Have you come to a decision for the upper constraint? Rails 8 is now released and this is blocking the upgrade. 😢 |
|
I cam merge this without a release and you can point it to the master branch. Will that work for you? |
Sure thing! |
|
@Schwad could you reintroduce the constraint and fix the conflicts? I'm sorry for taking so long. |
…s versions (#100) See svenfuchs/rails-i18n#1130 (comment) for upper constraint removal
Ref: #962