5 ms·

Perhaps an unpopular take, but what is described in the first paragraph as "smoother, easier and faster" than ever seems to refer to an upgrade process that has

Perhaps an unpopular take, but what is described in the first paragraph as "smoother, easier and faster" than ever seems to refer to an upgrade process that has been going on for over a year. > As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. > Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits. Once our build for Rails 6.0 was green, we’d merge the pull request to master, and all new code that went into GitHub would need to pass in Rails 5.2 and the newest master build of Rails. Realistically how many hours of work went into this upgrade process then? Edit: I should add I think it really is wonderful that Github contributed so much to the new release and was so involved. I'm just not sure that it is realistic or even ideal for the average Rails consumer to upgrade in this manner.

AlchemistCamp 7y ago
> how many hours of work went into this upgrade process then? It's hard to say, but I generally agree with upgrading regularly instead of waiting until you're so far behind that it's an ordeal.
- atonse 7y ago
  Agreed. The problem happens with convincing your clients to pay you to do so. I have a client that I've been telling for 2+ years to upgrade from Rails 4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+ years of upgrades and it's a huge headache. And at the end of it, if I've done my job correctly, the app will look identical.
  - bdcravens 7y ago
    I would point clients to the Rails support policy, and have the same support policy. https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html
  - KurtMueller 7y ago
    Rails at least has upgrade guides and a script that allows you to upgrade the app. It helps to go from one point relase to the next. I also find the Railsdiff web app helpful in comparing changes from one release to another. It's definitely not perfect or pain free though. I also hope you have a good test suite :). Good luck.
  - ksec 7y ago
    I have been wondering, if it is possible to charge client on yearly upgrade. Or Maintenance fees on a Framework / Security bases. Try to sell it to them like iOS update, you get security update from each framework upgrade. And should this not be a easier sell?
- aflag 7y ago
  It sounds nice to keep up. But I'm not sure if it's more efficient or not. Do you know about any study on this?
stevenwoo 7y ago
That's a good question, but I also appreciate that a company with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they should have said they could have waited but if one has the developer resources, it's better to be proactive instead of waiting for an official release and all of the sudden try to upgrade and run into a lot of unforeseen issues.
runako 7y ago
> Realistically how many hours of work went into this upgrade process then? Rails 6 is not a month old yet. What this describes is co-development, over the last year, of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project: > We were able to achieve this level of stability for the upgrade because we were heavily involved with its development. This is not representative of a traditional upgrade.
- FanaHOVA 7y ago
  And that's for GitHub, the #65 most visited website in the world, just to put it in perspective.
ulisesrmzroche 7y ago
This is a big app. It’s a lot different than upgrading toy apps. Is the average rails consumer just making toys?
- Axsuul 7y ago
  Are you basing the average on one person's experience?
technoweenie 7y ago
> Realistically how many hours of work went into this upgrade process then? Eileen wrote about the actual process a year ago when GitHub upgraded from Rails 3.2 -> 5.2: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...
kenhwang 7y ago
I just did an upgrade from 4.2 to 6.0 and the process was definitely much smoother than previous Rails upgrades, suspiciously so. Glad people are working on improving the upgrade path because it used to be rather painful.
- dzader 7y ago
  I just recently did an upgrade from 4.2 to 5.2 and was expecting a lot of pain - turned out it was incredibly simple and pretty much painless. Awesome to hear others are having the same experience!
dwheeler 7y ago
It's probably not realistic for the average Rails consumer to constantly run tests against master. Indeed, that's probably true for every framework, not just Rails. But it's definitely excellent for some sites to test against their framework's master branch. If nothing else, that greatly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users). You should have a test suite anyway, so modifying your CI to also run against the master of a key upstream may not be as bad as you think.
mokkol 7y ago
While they were upgrading, Github added a lot of their own core features into Rails itself. Like multiple databases supported by default, parallel tests for a much faster test suite. Github didnt just upgrade their Rails version, they upgraded Rails itself partly.

AlchemistCamp 7y ago

> how many hours of work went into this upgrade process then? It's hard to say, but I generally agree with upgrading regularly instead of waiting until you're so far behind that it's an ordeal.

atonse 7y ago
Agreed. The problem happens with convincing your clients to pay you to do so. I have a client that I've been telling for 2+ years to upgrade from Rails 4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+ years of upgrades and it's a huge headache. And at the end of it, if I've done my job correctly, the app will look identical.
- bdcravens 7y ago
  I would point clients to the Rails support policy, and have the same support policy. https://guides.rubyonrails.org/maintenance_policy.html https://guides.rubyonrails.org/maintenance_policy.html
- KurtMueller 7y ago
  Rails at least has upgrade guides and a script that allows you to upgrade the app. It helps to go from one point relase to the next. I also find the Railsdiff web app helpful in comparing changes from one release to another. It's definitely not perfect or pain free though. I also hope you have a good test suite :). Good luck.
- ksec 7y ago
  I have been wondering, if it is possible to charge client on yearly upgrade. Or Maintenance fees on a Framework / Security bases. Try to sell it to them like iOS update, you get security update from each framework upgrade. And should this not be a easier sell?
aflag 7y ago
It sounds nice to keep up. But I'm not sure if it's more efficient or not. Do you know about any study on this?

stevenwoo 7y ago

That's a good question, but I also appreciate that a company with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they should have said they could have waited but if one has the developer resources, it's better to be proactive instead of waiting for an official release and all of the sudden try to upgrade and run into a lot of unforeseen issues.

runako 7y ago

> Realistically how many hours of work went into this upgrade process then? Rails 6 is not a month old yet. What this describes is co-development, over the last year, of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project: > We were able to achieve this level of stability for the upgrade because we were heavily involved with its development. This is not representative of a traditional upgrade.

FanaHOVA 7y ago
And that's for GitHub, the #65 most visited website in the world, just to put it in perspective.

ulisesrmzroche 7y ago

This is a big app. It’s a lot different than upgrading toy apps. Is the average rails consumer just making toys?

Axsuul 7y ago
Are you basing the average on one person's experience?

technoweenie 7y ago

> Realistically how many hours of work went into this upgrade process then? Eileen wrote about the actual process a year ago when GitHub upgraded from Rails 3.2 -> 5.2: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...

kenhwang 7y ago

I just did an upgrade from 4.2 to 6.0 and the process was definitely much smoother than previous Rails upgrades, suspiciously so. Glad people are working on improving the upgrade path because it used to be rather painful.

dzader 7y ago
I just recently did an upgrade from 4.2 to 5.2 and was expecting a lot of pain - turned out it was incredibly simple and pretty much painless. Awesome to hear others are having the same experience!

dwheeler 7y ago

It's probably not realistic for the average Rails consumer to constantly run tests against master. Indeed, that's probably true for every framework, not just Rails. But it's definitely excellent for some sites to test against their framework's master branch. If nothing else, that greatly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users). You should have a test suite anyway, so modifying your CI to also run against the master of a key upstream may not be as bad as you think.

mokkol 7y ago

While they were upgrading, Github added a lot of their own core features into Rails itself. Like multiple databases supported by default, parallel tests for a much faster test suite. Github didnt just upgrade their Rails version, they upgraded Rails itself partly.