>Now on the one hand, this forces users to upgrade at least once per year.
The problem with this article is this assumption which is not true in the slightest.
There's no force which makes users upgrade - some users will upgrade when they're told; some will wait 5 or more years - and may have good reason to.
> Nothing kills a bug report faster than “My network card worked in 4.4 but stopped working in 5.6.” Developers aren’t going to bisect five years of changes; you get to do that yourself.
This statement can translate into don't ever upgrade. Is that really the goal?
The goal appears to be something more along the lines of not capitulating to the worst-common-denominator. Designing your product and spending your efforts to carefully accommodate people who upgrade every few decades (give or take) results in an objectively worse product for everybody else.
Unless, of course, that customer is willing to front the money to make it worthwhile.
Does it really result in an objectively worse product, though? Subjectively, I can't but agree. But objectively?
Especially in an industry where we are constantly amazed by what people accomplished years ago. I question whether long term planning and acting is truly objectively worse.
Windows XP is my standard example. We remember them fondly, but things we take for granted today (WiFi, 64-bit, multiprocessor support, advanced power management including frequency scaling) all had to be kludged into XP because it was forced to stick around for so long, and was never as good at these things as Vista or 7. (I know we all hate Vista, but it did these things well)
A long lifecycle doesn't allow for the rapidly evolving hardware & software environments.
> Except for auto-upgrade run from cron every few days.
This sort of user-hostile behavior is guaranteed to make me take the time to open a shell and nuke your software from orbit with blasts of "rm -rf". Don't do this.
The author didn't say the developers wouldn't care, but that the extra effort means the developers wouldn't care enough.
Fixing a bug requires figuring out what's broken, and that's a lot easier when you know something broke between 4.7 and 4.8, than in any of the revisions between 4.4 and 5.6. (Especially if there were actually two latent bugs in 4.4, one of which got exposed in 4.8, and one of which got exposed in 5.2)
Their network card still would have broken at some point and they'd be in the same bind they are in now: A non-working critical part and at the mercy of the developers to identify and fix the bug.
Exactly this thing happened to me in an OpenBSD upgrade. My network card no longer worked. That prompted me to actually read the release notes, and I quickly found the reason.
"programmers wouldn't break things that are working"
So you want the world's best security experts to manually review every module of every program you use, as well as every piece of every operating system you want it to run on, to make sure there are 100% certainly no exploitable bugs that could require a fix down the line?
That's the same argument, but with reality applied.
Programmers don't "break things that are working", people find design flaws that could lead to remote exploitation. If you don't patch your stuff, enjoy being 0wned, not my problem. For the rest of the world, bleeding edge is the safest place to be.
Yes, yes I would love that. Though, as I noted, nobody expects that ideal to pan out.
Reality applied to many large organizations to the prospect that things may break on an upgrade translates to "don't upgrade."
And really, this isn't necessarily bad. So long as what isn't getting upgraded has been compartmentalized and does its job correctly. Consider, we don't even think about asking companies to upgrade processors on a yearly basis. Monitors? Good for years. Actually, pretty much all of the hardware.
The problem with this article is this assumption which is not true in the slightest.
There's no force which makes users upgrade - some users will upgrade when they're told; some will wait 5 or more years - and may have good reason to.
> Nothing kills a bug report faster than “My network card worked in 4.4 but stopped working in 5.6.” Developers aren’t going to bisect five years of changes; you get to do that yourself.
This statement can translate into don't ever upgrade. Is that really the goal?