4 ms·

> Upgrade early and upgrade often Not sure about the upgrade early. It’s a different kind of pain to be one of the first to use a new Rails version vs lagging

> Upgrade early and upgrade often Not sure about the upgrade early. It’s a different kind of pain to be one of the first to use a new Rails version vs lagging a couple of months behind.

mperham 8y ago
Waiting a few months is good. It's a reasonable strategy to wait for x.y.1 but Rails 5.2.0 was so stable that 5.2.1 took ~6 months to appear.
deleted 8y ago
[deleted]
gsnedders 8y ago
I think there's two sane options: * track master, and notice breakage as soon as possible (you get much smaller deltas when trying to figure out breakage, which is always a big help), and are able to fix it or report it upstream ASAP, or * hold off slightly till the new release has had more bugs found post-release.
- hartator 8y ago
  Main issue is more with other gems that need to be updated as well. It may take take months. You can't do that on your own.
  - lostapathy 8y ago
    You can't do them all, but you can certainly pitch in and submit patches. Outside rspec-related gems, upgrading usually isn't that hard. And like all open source, somebody has to do it.
  - craigmcnamara 8y ago
    Fork, use your fork, send a pull request. Almost every rails upgrade I make forks and send patches on gems that I need that I forgot about. I get good responsiveness and merge rates. Most of the time a gem needs to be able to support multiple rails versions, so in that case I usually send pull request setting up the Appraisal gem to test for appropriate compatibility.
komali2 8y ago
Yes we tried this once, with webpack 4, and realized in about an hour that like half our packages were incompatible and had patches weeks out. I'm talking big packages, less-loader. Htmlwepbackplugin still requires @next for webpack4 to work right.
tetha 8y ago
I agree, at least for anything that's hard to test and has some inertia, like a larger code base. For example most of our configuration management is setup to just pull in the latest cookbooks from upstream during tests, and as long as all integration tests across all projects succeed, they get uploaded to our chef-server. People argued that it would be annoying because things would break all the time. And yeah, things break with updates, though the opscode community is remarkably disciplined about semver. But that's what we have tests for. And honestly: I'd rather deal with one broken update per day than 300 broken updates once per year. One bad update usually requires some nudging and that's it. 300 bad updates at once are a fully blown nightmare and you'll need days just to figure out what is even going on.
titusjohnson 8y ago
Yeah, being a first adopter can be a pain, but I don't think that's what they're saying here. Github was 4 years and 2 major versions behind on upgrades. Upgrade Early does not mean Upgrade Instantly. I would argue that "lagging a couple of months behind" is upgrading early, because these upgrade horror stories always come out of companies that are years and years behind. Having some patience and waiting a little, combined with the discipline to not wait too long is part of a mature skillset.
Rapzid 8y ago
I'm not sure how GitHub can say they "learned" this yet. Wasn't their last rails upgrade also a huge ordeal and a blog post? How about get back to us in a few years and we'll see if you learned anything this time around.
craigmcnamara 8y ago
The Appraisal gem is excellent for ensuring compatibility across many Rails and Ruby versions. Adding it to a project with a good test suite is a pretty good guarantee of an easy upgrade.

> Upgrade early and upgrade often Not sure about the upgrade early. It’s a different kind of pain to be one of the first to use a new Rails version vs lagging a couple of months behind.

mperham 8y ago

Waiting a few months is good. It's a reasonable strategy to wait for x.y.1 but Rails 5.2.0 was so stable that 5.2.1 took ~6 months to appear.

deleted 8y ago

[deleted]

gsnedders 8y ago

I think there's two sane options: * track master, and notice breakage as soon as possible (you get much smaller deltas when trying to figure out breakage, which is always a big help), and are able to fix it or report it upstream ASAP, or * hold off slightly till the new release has had more bugs found post-release.

hartator 8y ago
Main issue is more with other gems that need to be updated as well. It may take take months. You can't do that on your own.
- lostapathy 8y ago
  You can't do them all, but you can certainly pitch in and submit patches. Outside rspec-related gems, upgrading usually isn't that hard. And like all open source, somebody has to do it.
- craigmcnamara 8y ago
  Fork, use your fork, send a pull request. Almost every rails upgrade I make forks and send patches on gems that I need that I forgot about. I get good responsiveness and merge rates. Most of the time a gem needs to be able to support multiple rails versions, so in that case I usually send pull request setting up the Appraisal gem to test for appropriate compatibility.

komali2 8y ago

Yes we tried this once, with webpack 4, and realized in about an hour that like half our packages were incompatible and had patches weeks out. I'm talking big packages, less-loader. Htmlwepbackplugin still requires @next for webpack4 to work right.

tetha 8y ago

I agree, at least for anything that's hard to test and has some inertia, like a larger code base. For example most of our configuration management is setup to just pull in the latest cookbooks from upstream during tests, and as long as all integration tests across all projects succeed, they get uploaded to our chef-server. People argued that it would be annoying because things would break all the time. And yeah, things break with updates, though the opscode community is remarkably disciplined about semver. But that's what we have tests for. And honestly: I'd rather deal with one broken update per day than 300 broken updates once per year. One bad update usually requires some nudging and that's it. 300 bad updates at once are a fully blown nightmare and you'll need days just to figure out what is even going on.

titusjohnson 8y ago

Yeah, being a first adopter can be a pain, but I don't think that's what they're saying here. Github was 4 years and 2 major versions behind on upgrades. Upgrade Early does not mean Upgrade Instantly. I would argue that "lagging a couple of months behind" is upgrading early, because these upgrade horror stories always come out of companies that are years and years behind. Having some patience and waiting a little, combined with the discipline to not wait too long is part of a mature skillset.

Rapzid 8y ago

I'm not sure how GitHub can say they "learned" this yet. Wasn't their last rails upgrade also a huge ordeal and a blog post? How about get back to us in a few years and we'll see if you learned anything this time around.

craigmcnamara 8y ago

The Appraisal gem is excellent for ensuring compatibility across many Rails and Ruby versions. Adding it to a project with a good test suite is a pretty good guarantee of an easy upgrade.