Upgrading to Rails 3.2.22.5 from 3.2.21 (that’s just the first step, I’m incrementally bringing the project up to current version). Docs seem to say that preferred Ruby version is 2.2, so I upgraded to 2.2.10. When trying to install Rails 3.2.22.5, got the following error:
Installing rack-cache 1.11.0 (was 1.5.1)
Gem::RuntimeRequirementNotMetError: rack-cache requires Ruby version >= 2.3.0. The current ruby version is 2.2.0.
I expected to have dependency issues with my 3rd party gems, but I wasn’t prepared for this type of error with the core parts of Rails. Any idea how to resolve this?
This gem is *not* part of Rails.
Go to the gem's GitHub repo and look at the gemspec for available
versions to find the last one to work with Ruby < 2.3.0. Then pin
that version in your Gemfile.
You'll be doing this a lot, I imagine 
Good luck!
···
On Fri, Mar 6, 2020 at 11:52 AM Jack Royal-Gordon <jackrg@pobox.com> wrote:
Upgrading to Rails 3.2.22.5 from 3.2.21 (that’s just the first step, I’m incrementally bringing the project up to current version). Docs seem to say that preferred Ruby version is 2.2, so I upgraded to 2.2.10. When trying to install Rails 3.2.22.5, got the following error:
Installing rack-cache 1.11.0 (was 1.5.1)
Gem::RuntimeRequirementNotMetError: rack-cache requires Ruby version >= 2.3.0. The current ruby version is 2.2.0.
I expected to have dependency issues with my 3rd party gems, but I wasn’t prepared for this type of error with the core parts of Rails. Any idea how to resolve this?
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote
Thanks, Hassan, although I think the correct emoji would be 
or maybe 
.
···
On Mar 6, 2020, at 12:27 PM, Hassan Schroeder <hassan.schroeder@gmail.com> wrote:
On Fri, Mar 6, 2020 at 11:52 AM Jack Royal-Gordon <jackrg@pobox.com> wrote:
Upgrading to Rails 3.2.22.5 from 3.2.21 (that’s just the first step, I’m incrementally bringing the project up to current version). Docs seem to say that preferred Ruby version is 2.2, so I upgraded to 2.2.10. When trying to install Rails 3.2.22.5, got the following error:
Installing rack-cache 1.11.0 (was 1.5.1)
Gem::RuntimeRequirementNotMetError: rack-cache requires Ruby version >= 2.3.0. The current ruby version is 2.2.0.
I expected to have dependency issues with my 3rd party gems, but I wasn’t prepared for this type of error with the core parts of Rails. Any idea how to resolve this?
This gem is *not* part of Rails.
Go to the gem's GitHub repo and look at the gemspec for available
versions to find the last one to work with Ruby < 2.3.0. Then pin
that version in your Gemfile.
You'll be doing this a lot, I imagine
Good luck!
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Thanks, Hassan, although I think the correct emoji would be 
or maybe 
Rails 3.2 is very old and unmaintained
https://contributors.rubyonrails.org/releases
Don’t expect it to be a smooth ride. Does not need to be a nightmare if
just upgrading and you got the dependencies locked, but still. Gems move on.
···
On Fri, 6 Mar 2020 at 21:29, Jack Royal-Gordon <jackrg@pobox.com> wrote:
--
Sent from Gmail Mobile
I get it, but where I stand is that the app is stable on 3.2.21, and I need to upgrade it to a more recent (supported) version of Rails. I got some advice that indicated that I should move up minor version by minor version, and that the first step would be to move to 3.2.22.5 (last stable version of 3.2) before moving up from there. Under the circumstances, since that’s not going so well, might it make sense to skip that step and go directly to 4.0.13? Seems like I *might* miss some deprecation warnings if I do that, but if it saves major headaches the tradeoff might be worth it. Opinions?
···
On Mar 6, 2020, at 12:57 PM, Xavier Noria <fxn@hashref.com> wrote:
On Fri, 6 Mar 2020 at 21:29, Jack Royal-Gordon <jackrg@pobox.com <mailto:jackrg@pobox.com>> wrote:
Thanks, Hassan, although I think the correct emoji would be or maybe
Rails 3.2 is very old and unmaintained
Rails Contributors - Rails Releases
Don’t expect it to be a smooth ride. Does not need to be a nightmare if just upgrading and you got the dependencies locked, but still. Gems move on.
--
Sent from Gmail Mobile
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Probably depends a bit on how good your automated test suite is.
If you have a good test suite I actually generally prefer to make a giant
leap to the latest. Avoids me having to solve problems that exist on
versions in between but that don't exist on the latest. That being said if
you aren't that familiar with Rails an incremental approach may be better
as it will take it a piece at a time vs being given everything to do at
once.
Regardless of strategy a good test suite is keep to any upgrade (big or
small).
Eric
···
On Fri, Mar 6, 2020 at 4:15 PM Jack Royal-Gordon <jackrg@pobox.com> wrote:
I get it, but where I stand is that the app is stable on 3.2.21, and I
need to upgrade it to a more recent (supported) version of Rails. I got
some advice that indicated that I should move up minor version by minor
version, and that the first step would be to move to 3.2.22.5 (last stable
version of 3.2) before moving up from there. Under the circumstances, since
that’s not going so well, might it make sense to skip that step and go
directly to 4.0.13? Seems like I *might* miss some deprecation warnings if
I do that, but if it saves major headaches the tradeoff might be worth it.
Opinions?
On Mar 6, 2020, at 12:57 PM, Xavier Noria <fxn@hashref.com> wrote:
On Fri, 6 Mar 2020 at 21:29, Jack Royal-Gordon <jackrg@pobox.com> wrote:
Thanks, Hassan, although I think the correct emoji would be or maybe
Rails 3.2 is very old and unmaintained
Rails Contributors - Rails Releases
Don’t expect it to be a smooth ride. Does not need to be a nightmare if
just upgrading and you got the dependencies locked, but still. Gems move on.
--
Sent from Gmail Mobile
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe
<ruby-talk-request@ruby-lang.org?subject=unsubscribe>>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Going for Rails 4 might be more practical if you hit a wall.
In that page I linked you can see the commits for each version. They are
not many, and their messages will allow you to discard the majority of them
as not important for an upgrade. Perhaps you can do a pass in a sit and go
for it.
···
On Fri, 6 Mar 2020 at 22:15, Jack Royal-Gordon <jackrg@pobox.com> wrote:
I get it, but where I stand is that the app is stable on 3.2.21, and I
need to upgrade it to a more recent (supported) version of Rails. I got
some advice that indicated that I should move up minor version by minor
version, and that the first step would be to move to 3.2.22.5 (last stable
version of 3.2) before moving up from there. Under the circumstances, since
that’s not going so well, might it make sense to skip that step and go
directly to 4.0.13? Seems like I *might* miss some deprecation warnings if
I do that, but if it saves major headaches the tradeoff might be worth it.
Opinions?
On Mar 6, 2020, at 12:57 PM, Xavier Noria <fxn@hashref.com> wrote:
On Fri, 6 Mar 2020 at 21:29, Jack Royal-Gordon <jackrg@pobox.com> wrote:
Thanks, Hassan, although I think the correct emoji would be or maybe
Rails 3.2 is very old and unmaintained
Rails Contributors - Rails Releases
Don’t expect it to be a smooth ride. Does not need to be a nightmare if
just upgrading and you got the dependencies locked, but still. Gems move on.
--
Sent from Gmail Mobile
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe
<ruby-talk-request@ruby-lang.org?subject=unsubscribe>>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
Sent from Gmail Mobile
"It depends" variables:
* how much time do you have?
* how many people are working on it?
* are features being added while you're trying to upgrade?
* has anyone there done a significant upgrade?
* how complete is your test suite?
Just based on what you've said so far, I'd still recommend doing the
short trip to 3.2.22.5 as practice. Then go to 4.0.x and if you're feeling
confident jump to 5.0.x.
Doing essentially a rewrite by moving stuff into a bare Rails 5 app
is a valid approach too, but again, it depends.
There is really no scenario where you don't still have to sort out the
changed gem dependencies and rewrite a bunch of code, though.
Good luck!
···
On Fri, Mar 6, 2020 at 1:15 PM Jack Royal-Gordon <jackrg@pobox.com> wrote:
I get it, but where I stand is that the app is stable on 3.2.21, and I need to upgrade it to a more recent (supported) version of Rails. I got some advice that indicated that I should move up minor version by minor version, and that the first step would be to move to 3.2.22.5 (last stable version of 3.2) before moving up from there. Under the circumstances, since that’s not going so well, might it make sense to skip that step and go directly to 4.0.13? Seems like I *might* miss some deprecation warnings if I do that, but if it saves major headaches the tradeoff might be worth it. Opinions?
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote
First off, most people refer to versions as major.minor.bug, so bumping minor would mean going to 3.3.<latest>. Honestly, you're going to go through hell this way as you'll still be on unsupported ruby versions.
And if you have some unbound dependencies in your gemfile that will make it harder as well as some will try to update to the latest and greatest and that'll blow up further. If that's the case use "~> major.minor" to see if that slows it down.
If you're currently deprecation/warning free on your code, I'd skip 3.x and jump to 4. Get that cleaned up and verified, then jump to 5, etc... You're so far behind that this will be a bit painful, but 3->4 was a lot easier than 2->3 was.
···
On Mar 6, 2020, at 13:15, Jack Royal-Gordon <jackrg@pobox.com> wrote:
get it, but where I stand is that the app is stable on 3.2.21, and I need to upgrade it to a more recent (supported) version of Rails. I got some advice that indicated that I should move up minor version by minor version, and that the first step would be to move to 3.2.22.5 (last stable version of 3.2) before moving up from there. Under the circumstances, since that’s not going so well, might it make sense to skip that step and go directly to 4.0.13? Seems like I *might* miss some deprecation warnings if I do that, but if it saves major headaches the tradeoff might be worth it. Opinions?