Rhel 8 RoR3.xx : possible?

Hi If possible, i would like RoR3.xx et RedHat 8? if yes with Ruby version? I try a lot of choises without success. Where can i find documentation with Operating System / Ruby version / Ror version? Best regards

Your biggest problem with this scheme will probably be compiling Ruby old enough to run Rails 3. That’s gonna be 1.8.something, IIRC. That’s going to require an ancient version of libssl and other bits that have been deprecated for YEARS for very good reasons (they aren’t secure and might lead to dancing, etc.).

And then finding all the other gems that go along with that version of Rails, compiling any native parts of them in a really very modern OS when they want to harken back to the Bronze Age of Ruby development – this is all going to become a yak-shaving festival of epic proportions.

At least you will have Bundler and some Ruby version manager to help you with this exercise – it could be so much worse, and you could be talking about Rails 2.1 or similar, when you had to use the system Ruby and install all your gems once per machine…

Good luck, but also, be warned. This will go lateral on you and may cost a fortune in time or hair replacement.

Walter

Ok. But it is recommended to pass thru Rails 3 and Rail 4 and so on to migrate Rails 2 application. Do you thing it is better to jump from Rails 2 to Rails 7 ?

Oh wow. You buried the lede on that one!

At that degree of difference, it will be markedly faster to just re-build the app from scratch. rails new your-site-name-here in Rails 7, and then start duplicating the models and so forth over. There are SO MANY differences between Rails Then and Rails Now that it might as well be a different framework. Assuming you have built more than two new apps in Rails 7, you will probably be able to squint at the old app and see what it meant to do then. If it was an app you built long ago, you will have a tremendous advantage here, but even if not, a lot of the code patterns will reveal themselves to you if you stare long enough.

Rather than try to directly connect to the old database with the new app, you might want to create a new database, and then dump and restore the old data into new tables. Don’t just dump the entire database, because Rails best practices have changed a ton when it comes to the basic column formats for the various data types. Take advantage of all that progress and simply restore the table contents after you create the table from scratch, using the migrations from Rails 7.

Read through the CHANGELOG summaries that exist for every major and minor version between then and now, too. There are a number of things that were completely deprecated, and nobody but you (with the old source code in front of you) will know which ones to warn you about…

Finally, if you don’t know Rails 7 super-well, but you do know maybe Rails 6.0+ or 5.2, then do this re-write exercise starting from that version instead. The upgrades from 5.2 to 7 are both fewer and less extreme than they will be from 2.x.

Hope this helps, and good luck!

Walter

You may want to look here for an entry point to the changes: Ruby on Rails — Releases

Hi Walter thanks. I know it is a big work but it is a entreprise app! Until now we were blocked by documatic gem. For MySQL database, i already do the job from scratch. I don’t understand the benefit to pass thru rails. Do you have a document about this? BR

| Walter Davs walterdavis
October 21 |

  • | - |

Oh wow. You buried the lede on that one!

At that degree of difference, it will be markedly faster to just re-build the app from scratch. rails new your-site-name-here in Rails 7, and then start duplicating the models and so forth over. There are SO MANY differences between Rails Then and Rails Now that it might as well be a different framework. Assuming you have built more than two new apps in Rails 7, you will probably be able to squint at the old app and see what it meant to do then. If it was an app you built long ago, you will have a tremendous advantage here, but even if not, a lot of the code patterns will reveal themselves to you if you stare long enough.

Rather than try to directly connect to the old database with the new app, you might want to create a new database, and then dump and restore the old data into new tables. Don’t just dump the entire database, because Rails best practices have changed a ton when it comes to the basic column formats for the various data types. Take advantage of all that progress and simply restore the table contents after you create the table from scratch, using the migrations from Rails 7.

Read through the CHANGELOG summaries that exist for every major and minor version between then and now, too. There are a number of things that were completely deprecated, and nobody but you (with the old source code in front of you) will know which ones to warn you about…

Finally, if you don’t know Rails 7 super-well, but you do know maybe Rails 6.0+ or 5.2, then do this re-write exercise starting from that version instead. The upgrades from 5.2 to 7 are both fewer and less extreme than they will be from 2.x.

Hope this helps, and good luck!

Walter

You may want to look here for an entry point to the changes: Ruby on Rails — Releases

The Brick auto-recognises older versions of Rails and patches them so that applications will reliably run under Ruby 2.7 – just drop in the gem and it automatically does this. While at the moment the earliest Rails it can patch is 4.20, based on this thread I’ve gone in and updated things so at least ActiveRecord 3.2 stuff and controllers will now work. The view templates stuff isn’t yet going only due to frozen strings getting in the way. Will see if I can patch it further on the weekend to have any Rails 3.2 app run under Ruby 2.7.

(Friends don’t let friends run on Ruby < 2.7 !!!)