Ideally, with semantic versioning, yeh, a major version kind of implies there are breaking changes somewhere. But of course semantic versioning is a standard and you know what XKCD says about standards. Aside: shareware is something completely different.

As a developer and maintainer of both old lightly maintained code and packages that are effected by breaking changes I can't agree. Any change that breaks existing code is a breaking change, regardless of how broad the changes to support it are. An undocumented breaking change and a documented breaking change just differ in how likely it is that you will notice it ahead of time. If you are actively monitoring the source repos, you will catch it whether it makes release notes or not, and makingthe release notes doesn't mean it gets caught before release... especially with automagic repo updates upstream that sneak changes in that suddenly break docker or nix builds. As a package maintainer, any change that requires the customer to edit their code at all is treated as a breaking change. We work very hard to make sure that old code continues to build without modification. If new code won't work on older versions, like we've added an API call but haven't changed any, or changed the meaning of a parameter in a backwards-compatible way, that's not a breaking change. If we've changed an existing API call so code has to be modified, that's a breaking change.

"However, simply changing a function name or its signature, and providing release notes so that users can easily convert to the new interface, shouldn't be considered a breaking change." If not, then what would be considered a breaking change? An undocumented one?

A boy has never wept nor dashed a thousand kim.

I don't think we disagree on Apple's hardware ecosystem, which is the bit that confuses me. Their hardware is anemic and restricted and overpriced, and it's part of the cost of the OS. The OS, on the other hand, plays very nice with the other children. I do UNIX, and my Mac makes a pretty good and pretty standards-compliant UNIX that happens to have a pretty good local app ecosystem on top of that. Remember, my original point was about Microsoft *advertising* a standards compliant platform (C++, the POSIX subsystem) but locking you into their proprietary environment if you actually tried to make use of it. Apple is exactly the opposite. Right now I have my Mac mini, a Linux laptop, a Linux firewall, and a handful of FreeBSD- and Linux-based servers. They all work together and I can run the same programs and scripts on any of them. I can even ssh -X to a server and run Firefox or whatever natively on my Mac without having to use a screen-scraper like VNC or Remote Desktop. My Windows laptop, on the other hand, is basically a game machine with a web browser. Apple in the '80s and '90s, before the switch to UNIX, was a whole different company. It's been 20 years since they abandoned their funky and exclusively proprietary desktop.

I'm not sure what you're getting at here. Apple and Microsoft both have serious problems, but I don't see how Apple's problems are related to Microsoft's passive-aggressive implementations of standards. Apple's standard interfaces are generally quite good as open standards (open systems, open source, standard interfaces and APIs) practices go. Their issues are mostly not providing open interfaces on their mobile devices at all (something that Microsoft started doing as well as Pocket PC phone edition turned into Windows Powered and Windows Phone), and of course their restriction of their OS to their somewhat anemic and siloed hardware.

Oh dear. Yes, I know how to use it. I have written code on both DOS and Windows for over 40 years now, and even when I was doing it every day it was at best annoying, the API is hodge-podge and the scripting environment fragmented worse then '80s UNIX. I would rather code for 6th Edition from 1976 (even with the funky 6th edition shell). The Amiga was amazing. The message-passing real-time OS underlying AmigaDOS was really intuitive: even for low level work - you could write device drivers just by having a program post a message port and respond to appropriate messages - and the API was the best I have ever used "live fire" for low-level concurrent programming. It's a pity the business-feud-turned-personal between Tramiel and Gould doomed it from the start.

Microsoft tends to implement standards reluctantly and using every possible misinterpretation to encourage people to use their proprietary APIs instead. Their POSIX subsystem was a perfect example. They deliberately crippled it and defended their misfeatures as "we're just following the standard as we see it". When a company implemented an actually useful UNIX API on top of it, they bought them and took it off the market for several years... finally exposing it as part of their Windows Services for UNIX which at first was only available on NT Server. You exactly nailed it. The passive-aggressive standards conformance is a "feature".

Developing software on Windows is too great a burden for anything associated with it to rise to the level of "decent". I can not comment on gaming hardware. The last time I did much gaming was when I was developing Tracers on the Amiga 1000.

I have been using the entry level Microsoft optical mouse for over 20 years now. For a while they got hard to find among the horrid multi-button gimmicky devices so I bought a batch from Goodwill for a few bucks each and worked through these weary warriors until I could get new again. The only decent product the company ever made. And now they're discontinuing them.

Because wireless desktop devices have betrayed me too many times for me to trust them when I don't have to. I will use a bluetooth mouse on my laptop when I'm on the go, but I have a USB mouse plugged into my docking hub at home.