6 ms·

For those of you keeping score: - Yes, Rails 3 was released four years ago - Yes, the current stable version is Rails 4.1, which left us two

• reedlaw 12y ago
  It's usually wise to handle large transitions incrementally. Rails 3 before Rails 4 is probably a wise choice.
  • technoweenie 12y ago
    Work has started on the move to 3.2: https://twitter.com/charliesome/status/511517393038753794 https://twitter.com/charliesome/status/511517393038753794
• jack_jennings 12y ago
  2 to 3 was a more difficult update. If I recall correctly, a feature of 4 was that the upgrade path was more reasonable.
• pothibo 12y ago
  Rails 4 support ruby > 1.9.3 whereas rails 3 supports 1.8.x. I believe this could be the main reason why they didn't move to Rails 4. Ruby 1.8.x -> Ruby 1.9.x requires quite some work by itself.
  • alttab 12y ago
    Mainly due to string encoding. For something like Github, mistakes there could be disastrous. With all of the special characters and user input there are bound to be wild edge cases.
  • thedaniel 12y ago
    We moved to Ruby 1.9+ quite a while ago with our patched-up Rails 2.3.
• elektronaut 12y ago
  Upgrading to 3.0 is a nice milestone, especially if you're porting over a large app. ActiveRecord 3.x still supports the query interface used in 2.3, I'm guessing this is how they're able to run both versions from the same codebase. I'm not sure which Ruby version GitHub is on, but Rails 4 requires Ruby 1.9+. Running Rails 2.3 on Ruby 1.9+ is doable but tricky.
  • alttab 12y ago
    Confirmed with 2.3 and 1.9+. We had a ton of encoding issues with that combination. We had to ensure every single thing was encoded properly.
• jeremycw 12y ago
  2.3 to 3.0 is not that bad. 3.0 -> 3.2 is where the trouble will begin. 3.0 deprecates a ton of stuff in 2.3. 3.2 actually removes it all and adds in the asset pipeline. Best to not bite off more than you can chew.
  • thedaniel 12y ago
    We had already backported a whole bunch of of stuff to 2.3 so hopefully the 3->3.2 transition won't be so terrible.
  • jrochkind1 12y ago
    In my experience, Rails 2->3 was, most decidely, _that bad_. It was the most difficult and frustrating migration I've ever done, and none of the subsequent Rails migrations have been close to as terrible. (The fact that 2->3 was, like for most, also ruby 1.8 to 1.9 probably contributed)
    • dasil003 12y ago
      For me 3.0 -> 3.1 transition was definitely the more painful transition, because it forced me to also do 1.8 -> 1.9 at the same time due to a performance regression that made the test suite jump from 20 minutes to 2.5 hours under 1.8.
      • sams99 12y ago
        GitHub are running 2.1.2 GitHub edition Ruby so that is a non-issue for them. 2 -> 3 migration is VERY VERY hard. 3 -> 4 should be relatively easy in comparison.
• donw 12y ago
  An important lesson I learned while working as a sysadmin was that when you're making operational changes, you do one thing at a time. Let's say you need to set up a replicated database with failover and monitoring. First you set up the database (and make sure it works). Then you set up monitoring (and make sure it works, too). Followed by replication (which should also work). And finally, automatic failover (there's a pattern here...) This sounds obvious, but I've worked with developers that, when given this task, tried to set up the entire thing in one shot. It took them over a month to wrap up, and they didn't have time to properly test it, because they bit off too much in one go. The same goes for migrations. You work along an incremental plan to move from Point A to Point B, where at every step of the way, the set of things you need to change is small enough to manage, and you have the option of rolling back. I can't imagine that Github has a tiny codebase, so I could totally believe six months for a zero-downtime Rails 2.x -> 3.0 migration. The next big step (3.0 -> 3.2) will be easier from what they learned in the first step, as will the step after that (my guess is 3.2 -> 4.0).
  • bduerst 12y ago
    That rule applies to more than just programming languages. The U.S. Healthcare system has tried to switch to ICD10 standards for a while now, but they keep bumping back the deadline. I think it's EOY 2015 right now. ICD10 was released in 1992...
  • tcopeland 12y ago
    Yup. Another advantage of doing things incrementally is you get used to doing things incrementally. So you get good at it, and the business folks get used to hearing "we're upgrading from x to y", and tech folks get used to thinking about the next piece that needs to be upgraded, etc.
  • danudey 12y ago
    My first task at my current job was to build a deployment system where people could deploy code using a website. After two and a half years, version 1.0 was essentially feature-complete (as far as minimal necessary components). Those two and a half years were spread over dozens of tools, a svn->git migration, two rewrites of the core functionality, but it all stayed on track because I was building small pieces which did limited things, and chained them together (the unix-y philosophy). I could build some functionality, test it, integrate it into the tool, and use it for a while. Then I could add support for it to our distributed RPC-ish system, and then if that worked, I could add it to our automated scripts. If I had to build the whole thing at once I probably would have ended up with a much nicer, cleaner design, a much worse product, and a far longer deadline, and we wouldn't have had useful automation tools for the two intervening years.
• Intrepidd 12y ago
  I actually went nuclear on a large rails project and migrated it from custom rails 2 fork to rails 4, it was a mess but we're glad we made the whole deal once instead of migrating slowly to 3.0, then 3.2, then 4. It took ~ 6 months as well.
• hobarrera 12y ago
  > Okay, so why didn't aren't they transitioning to Rails 4? If I had to guess, I'd say it's easier to hit Rails 3 as an intermediate milestone before moving onto Rails 4.