> I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this Again, I don't see why that only app

> I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this Again, I don't see why that only applies to open source. I've implemented both open source and proprietary software that have changed how they work after upgrades. Both have also provided long-term support on older versions to work the old way. When I say I build this into my workflow, the basis for this is understanding how the software I depend on is maintained. Things like Ubuntu, Django, Nginx, Postgres all have long and predictable lives if you opt into that. I can deploy something on 16.04 today an still deploy it on 16.04 in 2021. The infrastructure will have received security updates, but the APIs remain static. My software will continue to work as it always did. That's also how you'd aim to do it with proprietary software but you can still make bad decisions. If you insist on staying on the very latest everything (instead of opting for long term support versions) you will have to test and upgrade your application a lot more frequently. Just to round on Apple here, they're not perfect at this either. They make no commitment to how long their software will be supported and on average versions of OS X are supported around ⅔ the time Ubuntu LTS versions are. Ubuntu (or RHEL) are far better bases if you require a predictable and long-lasting product.