But with most companies' development process, you're stuck having to take the bad with the good. Their release tree is one long trunk, and to get the security updates you must also take the latest PM's pet features and the disruptive results of their latest UX designer's art project. Companies need to learn how to branch at major versions and offer minor maintenance releases on each of those branches, while offering the next version.
EDIT: If 'grep' was developed like most commercial/startup software, its command-line switches would all change with every release, it would require an internet connection, it would be able to grep through Tweets, and it would phone home to its developer with logs of every file you grep through.
I shouldn't have to accept whatever feature/UI madness developers have cooked up in order to have security issues fixed.
Nobody does because it causes a combinatorial explosion in code branches, and in testing. This isn't just a problem with the higher level convenience tools like compilers and package managers, its a problem with the actual source code as formulated as it is today. We'd need an entirely different way of writing code in order to do that without a massive increase in programmer/testing hours. Personally I don't think it will ever realistically happen, but I'd love to be proven wrong.
As a developer, I don't really understand. I've been working on large, complex software that targets multiple operating systems for years, and we don't have any such issues.
It sounds to me like a lot of companies are using development methodologies that are a bit broken...
I've long thought that the reason for this is rather different -- the industry really wants to go to continuous-release models (which I don't think is a good thing, but that's a separate issue), which make security-only releases a bit nonsensical.