Add Rails 8 Support #405
Add Rails 8 Support #405
Conversation
There was a problem hiding this comment.
Very nicely done! I think you can exclude the Ruby 1.9.3 / Rails 8 combination from the test matrix @OskarEichler, so that there are no failing test suites related to Rails 8.
Other than that, this is ready to go!
Side note: I'm not too sure about what's going on in the Ruby 2.6 / Rails 4 / Devise 3 combo, or which component is at fault, but that is unrelated to your changes so it's not a blocker.
|
@gonzalo-bulnes This is done - it's weird that rails_7_devise_4 failed, as it was successful in the run before |
There was a problem hiding this comment.
Thank you @OskarEichler!
Indeed, the rails_7_devise_4 suite succeeded on retry, which is not great, but unrelated to your PR.
I'll approve the PR for now and merge it as soon as I've got my signing gear handy 🙂
|
I am trying to upgrade a client application to Rails 8, and I was wondering when we can expect this PR to be merged. |
|
👋 That's a question that's harder to answer than it may look like @eclectic-coding because I get to interpret what you mean without really knowing it. And I'd hate for my reply to be misinterpreted. I'll try, please bear with me knowing I don't mean this reply to sound short or disregarding of what I believe is a genuine concern of yours. (Or patronizing or anything like that! 😬) I can't talk about yours or anyone's expectations. They are what they are. Now, that aside let's get to what I think is the core of your question, which I'll rephrase as: "I want to use this new Rails 8 support, and I need the PR to be merged for that!" First of all, I'm glad you do! That's why the gem is there in the first place! 🙂 Merge vs release Once I merge this PR, Is a gem release needed in order to use the Rails 8 supporting code? Actually not. The code is written (thanks @OskarEichler!), and GitHub attests that it has been reviewed by someone (me, of all people). At this point, outside of a verifiable signature of mine (which I assume is not what you're after), from a trust perspective things are pretty much how they're going to be once the new gem release is cut. By that I mean that there isn't much more reason to trust the released gem more than @OskarEichler branch at this point. Using the code in that branch is as simple as replacing the Gemfile line by: Ok-ish, maybe... am I settling for less? Believe me, I hear you. Please hear me out. Certainly, this isn't a long-term solution, since it would prevent you from getting future upgrades. That being said, for the purpose of kicking off a Rails 8 upgrade, and given the overall slow pace at which new Now, something that could make things even better, would be if someone could indeed test the code and confirm publicly if it behaves as they expect. That Gemfile tweak is the way to do that, and I would personally appreciate such a third-party confirmation before cutting a new release. I make mistakes, and if I had overlooked anything in my review I'd largely prefer finding out before making a release that after. So if you take that step, upgrade your app, and give that feedback, that would be a significant (and appreciated!) contribution. (Not everything is code in open-source.) To recap:
|
|
Hi @gonzalo-bulnes , thank you for you work? May I ask if you plan to release the change? It's blocking me from updating Rails yo 8 Thanks again! |
|
@palexvs You have to read the incredibly verbose comment above where Gonzalo pretended to not understand someone wondering when it was going to be merged. The short answer, though, is it is currently merged, and if you're like most people then you might not realize that you can look deeply into the comments of a merged PR to learn how to use bundler to point to an unreleased commit:
|
|
@RyanTG thank you. I have decided to go another way - fork it as temporary solution and migrating on something else in the future |
5 participants
@gonzalo-bulnes