Closed divergentdave closed 7 years ago
I think Ruby 2.3.1 is probably fine. While I'm not as plugged-in as I used to be, once the Ruby community made it off of 1.8, the gaps between version releases have been small and smooth. I would be surprised if we had any regressions for an upgrade.
I don't know about speeding up ruby-build. :/ There's been an open issue for shipping precompiled Rubies for 5 years: https://github.com/rbenv/ruby-build/issues/42 Further googling and research doesn't suggest other easy workarounds. Open to ideas, including abandoning rbenv on deployed servers in favor of wget
-ing a precompiled binary from somewhere, as long as it's a consistent and official or semi-official location.
How about switching to rvm instead of rbenv? I don't know much about either, but rvm is plenty quick on Travis CI.
Try it locally and see. It's very possible Travis caches rvm builds itself.
Okay, I installed rvm in a chroot and gave it a spin. It can install prebuilt binaries, if there's an appropriate version available on rvm.io or somewhere else. Installing a version from binaries takes about thirty seconds, but if binaries aren't available it automatically falls back to building from source, which can take several minutes. Of note, 2.1.10 isn't available on https://rvm.io/binaries/ubuntu/16.04/x86_64/. 2.3.1 and 2.3.3 are available in binary form.
2.3.3 sounds good to me. I'm all about keeping up with the latest version.
Right now, the latest stable ruby version is 2.3.1. The AWS instance configuration is installing 2.2.5 (building from source, I might add), the Travis CI configuration is installing 2.1.10, and the README says to install 2.2 or higher. (my development machine is using 2.1.5 FWIW)
We should pick a version (probably newer) for all of these and make them match. I'm insufficiently plugged-in to the ruby community to make a good judgement call. Thoughts?
While we're at it, is there a better solution for the EC2 instances than rbenv/ruby-build? Currently, building ruby 2.2.5 from source takes 5-10 minutes, and it's easily the longest part of the deployment process.