> These updates often contain security fixes. You risk by not updating on time.
Maybe they ought to unbundle security fixes from feature-upgrades. It's not a technical hurdle, it's a cultural one.
Maybe they ought to unbundle security fixes from feature-upgrades. It's not a technical hurdle, it's a cultural one.
On the technical side, release branches have been existed since forever - Microsoft has been doing this for decades instead of forcing upgrades to the latest windows/office version.
There are 2 possibilities:
1. Users who want to stay on old versions without access to the newer app store stay. This happens all the time with people who have old iPads they want to hand off to their kids/grandparents/whatever.
2. Apple stops pretending that there are enough new features every year to merit a major version of iOS, and gates updates for newer packages to only users of the newest phone. They already have the capability to do this for iPads, iPhone X, and others.
I think this is a case where Apple has to make a choice between their developers' convenience or their users' UX. I personally think developers should cater to multiple versions just like any other platform (targeting Android APIs, Windows releases, kernel versions).
Apple developers aren't special snowflakes. They can handle what other developers have been doing for as long as programmable computers existed.
Is there a good technical reason why a fix to their crypto library couldn't be backported?
This is exactly what Red Hat does, and Debian stable, and it works.
Red Hat only back-ports packages because they are paid to do so per their support contracts. And even under RHEL, you may have to upgrade to the latest packages (for your OS version) to receive support.
And anyway, if you don't trust your OS vendor to not try to screw you over (planned obsolescence) in major releases, why would you trust them for any update whatsoever? Lack of vendor trust is not something you solve through packaging.