5 ms·

...until you discover the feature you wanted is two major versions after yours, and you’ll spend days updating to the major version because you did not care to

...until you discover the feature you wanted is two major versions after yours, and you’ll spend days updating to the major version because you did not care to update. (eg reacr-router)

Waterluvian 8y ago
I'm happy to pay that cost once at one time than incrementally and may have never needed it.
- stouset 8y ago
  That one-time cost is at least an order of magnitude greater than the sum of the many-time costs, in my own experience. And that’s before you run into tangential problems like increased time to respond to security issues. Further, I would bet a large sum of money that the overwhelming majority of vulnerabilities discovered and patched in open-source libraries are never officially reported and never have a CVE or OSVDB entry; they are simply patched in situ with no announcement or fanfare.
  - spiritcat 8y ago
    Got to be at least partially offset by the likelihood of new code/major rewrites introducing vulns. Kinda curious how the numbers work out on this. Best to install patch updates but hold off on major versions by default?
    - stouset 8y ago
      This is what I generally advocate. Pin to a major version and ruthlessly update. Major versions are fine to delay until an opportune time, but never to the point where you're even close to being more than one major version behind.
- aequitas 8y ago
  Client: "What do you mean it will cost X money and Y time to fix this trivial bug/feature in our App? And whats this babbling about having to upgrade at least a dozen frameworks? I just want this simple thing changed, not have my entire App rebuild. Last time you did that everything else broke and it took forever to get all the new bugs sorted."
- cjsawyer 8y ago
  It’s the same as premature optimization
viraptor 8y ago
Or worse: find out you need a security fix and that a large dependency chain is more than one major version behind. The issue is publically known and easy to scan for. The clock is ticking...
- spiritcat 8y ago
  the dependency is open source ya? if upgrading is that bad can always (usually) patch it yourself
- flukus 8y ago
  That would be your own fault for using immature libraries that don't offer stable versions with security and bug fixes. Unfortunately that's most of the npm library and a growing problem in other ecosystems.
  - viraptor 8y ago
    I commented with a realistic and common use case in mind. We can talk idealistic / paranoid scenarios too, but that's just not how majority of developers work, so it's a bit of a moot point.
    - flukus 8y ago
      > We can talk idealistic / paranoid scenarios too Have we sunk that low that the idea of using mature, stable and supported libraries is idealistic and paranoid now? It used to just be called responsible. > but that's just not how majority of developers work, so it's a bit of a moot point I don't think identifying the root cause of an issue is ever a moot point.
- taneq 8y ago
  YAGNI (at least until YNI)?
mercer 8y ago
I think that's good reason to do some research on the main packages your rely on. I've been burned by react-router more than once, so for my last few projects I went for a much older, stabler package (I think it was page.js). I didn't impact my project much, but saved me from dealing with the react-router hell of tight coupling with react combined with a history of ridiculous non-backwards-compatible updates.
justinmchase 8y ago
npm doesn't auto update major versions by default anyway. So you will likely need to spend the same amount of work but during unscheduled time, updating code for features you didn't even need yet. It can be very disruptive to work in progress.

...until you discover the feature you wanted is two major versions after yours, and you’ll spend days updating to the major version because you did not care to update. (eg reacr-router)

Waterluvian 8y ago

I'm happy to pay that cost once at one time than incrementally and may have never needed it.

stouset 8y ago
That one-time cost is at least an order of magnitude greater than the sum of the many-time costs, in my own experience. And that’s before you run into tangential problems like increased time to respond to security issues. Further, I would bet a large sum of money that the overwhelming majority of vulnerabilities discovered and patched in open-source libraries are never officially reported and never have a CVE or OSVDB entry; they are simply patched in situ with no announcement or fanfare.
- spiritcat 8y ago
  Got to be at least partially offset by the likelihood of new code/major rewrites introducing vulns. Kinda curious how the numbers work out on this. Best to install patch updates but hold off on major versions by default?
  - stouset 8y ago
    This is what I generally advocate. Pin to a major version and ruthlessly update. Major versions are fine to delay until an opportune time, but never to the point where you're even close to being more than one major version behind.
aequitas 8y ago
Client: "What do you mean it will cost X money and Y time to fix this trivial bug/feature in our App? And whats this babbling about having to upgrade at least a dozen frameworks? I just want this simple thing changed, not have my entire App rebuild. Last time you did that everything else broke and it took forever to get all the new bugs sorted."
cjsawyer 8y ago
It’s the same as premature optimization

viraptor 8y ago

Or worse: find out you need a security fix and that a large dependency chain is more than one major version behind. The issue is publically known and easy to scan for. The clock is ticking...

spiritcat 8y ago
the dependency is open source ya? if upgrading is that bad can always (usually) patch it yourself
flukus 8y ago
That would be your own fault for using immature libraries that don't offer stable versions with security and bug fixes. Unfortunately that's most of the npm library and a growing problem in other ecosystems.
- viraptor 8y ago
  I commented with a realistic and common use case in mind. We can talk idealistic / paranoid scenarios too, but that's just not how majority of developers work, so it's a bit of a moot point.
  - flukus 8y ago
    > We can talk idealistic / paranoid scenarios too Have we sunk that low that the idea of using mature, stable and supported libraries is idealistic and paranoid now? It used to just be called responsible. > but that's just not how majority of developers work, so it's a bit of a moot point I don't think identifying the root cause of an issue is ever a moot point.
taneq 8y ago
YAGNI (at least until YNI)?

mercer 8y ago

I think that's good reason to do some research on the main packages your rely on. I've been burned by react-router more than once, so for my last few projects I went for a much older, stabler package (I think it was page.js). I didn't impact my project much, but saved me from dealing with the react-router hell of tight coupling with react combined with a history of ridiculous non-backwards-compatible updates.

justinmchase 8y ago

npm doesn't auto update major versions by default anyway. So you will likely need to spend the same amount of work but during unscheduled time, updating code for features you didn't even need yet. It can be very disruptive to work in progress.