5 ms·

I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a whil

by aflag 7y ago

I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a while?

beaniebabies 7y ago
I also update the npm packages for a small website weekly. It's much easier fixing a few occasional breaking changes than waiting for a year and then having a massive headache since nothing will compile/work anymore.
timdorr 7y ago
Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don't have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error prone. It's worthwhile to keep up to date. It's probably not worthwhile to upgrade ASAP after a release, but you don't want to wait too long.
rhizome 7y ago
I tell you what, say what you will about having plenty of warning, but right now I'm big-bang-ishly updating an app to 5.2 and I'm mired in quicksand due to the death of both bourbon/neat (removal of the most interesting functionality) and paperclip.
- jrochkind1 7y ago
  I agree that conflicts/integrations between dependencies tend to give more upgrade pain than conflicts with local code and a single dependency. I think probably exactly how often to upgrade all your dependencies on what schedule... depends on the particular product and organization and resource-richness. What Github's did, upgrading Rails _daily_ to the latest non-release master... sounds really attractive if you can do it, but I suspect most people can't. A step on the way would be just `bundle update`ing daily and making sure to keep up with always having that passing and deployed. (Although in Github's case I don't think the actually deployed with dependency on unrelased master). I don't actually really even do that, def haven't automated it (although it occurs to me it would be simple to automate on travis or probably equivalent).
stevenwoo 7y ago
I have had to take over multiple projects that were years out of date on multiple platforms/os/languages. It's a nightmare that one does not wish on anybody, it's possible but as the other poster notes, one has to have extensive testing suite to verify functionality before and after - or one has to make one to have any hope of succeeding (making a final product up to date and functioning correctly unless one just wants to make something just run.) It's never as easy as just changing the lib/imports since active languages/libraries are living things, to say nothing of dead libraries that one has to update or replace.
- tmm84 7y ago
  I agree 100% with this. I once had a project that was versions behind the current platform. I couldn't upgrade because the tools to upgrade were gone and I was constantly having to fire off questions to the lead contributor who was around for that version in order to get stuff done. Upgrade as soon as a stable build of the major version is released and pay the engineering costs or be left with something worse than legacy.

by aflag 7y ago

I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a while?

beaniebabies 7y ago

I also update the npm packages for a small website weekly. It's much easier fixing a few occasional breaking changes than waiting for a year and then having a massive headache since nothing will compile/work anymore.

timdorr 7y ago

Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don't have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error prone. It's worthwhile to keep up to date. It's probably not worthwhile to upgrade ASAP after a release, but you don't want to wait too long.

rhizome 7y ago

I tell you what, say what you will about having plenty of warning, but right now I'm big-bang-ishly updating an app to 5.2 and I'm mired in quicksand due to the death of both bourbon/neat (removal of the most interesting functionality) and paperclip.

jrochkind1 7y ago
I agree that conflicts/integrations between dependencies tend to give more upgrade pain than conflicts with local code and a single dependency. I think probably exactly how often to upgrade all your dependencies on what schedule... depends on the particular product and organization and resource-richness. What Github's did, upgrading Rails _daily_ to the latest non-release master... sounds really attractive if you can do it, but I suspect most people can't. A step on the way would be just `bundle update`ing daily and making sure to keep up with always having that passing and deployed. (Although in Github's case I don't think the actually deployed with dependency on unrelased master). I don't actually really even do that, def haven't automated it (although it occurs to me it would be simple to automate on travis or probably equivalent).

stevenwoo 7y ago

I have had to take over multiple projects that were years out of date on multiple platforms/os/languages. It's a nightmare that one does not wish on anybody, it's possible but as the other poster notes, one has to have extensive testing suite to verify functionality before and after - or one has to make one to have any hope of succeeding (making a final product up to date and functioning correctly unless one just wants to make something just run.) It's never as easy as just changing the lib/imports since active languages/libraries are living things, to say nothing of dead libraries that one has to update or replace.

tmm84 7y ago
I agree 100% with this. I once had a project that was versions behind the current platform. I couldn't upgrade because the tools to upgrade were gone and I was constantly having to fire off questions to the lead contributor who was around for that version in order to get stuff done. Upgrade as soon as a stable build of the major version is released and pay the engineering costs or be left with something worse than legacy.