GNU Make 4.0 released

It's not an ABI since it's not used when program is run. It's only used when program is build. And kernel is known for such breakage. You can not just grab random new version of kernel headers and build userspace program. You can read lovely discussion on the topic here. Note that opinions of kernel developers differ and not all of them are in favor of fixing the stuff. Yet, such changes sometimes are introduced on purpose (as happened recently).

It's not a big deal if a regression sometimes slips through, but they ought to be fixed if at all possible.

Nope. They should be fixed when feasible. Gentoo was able to mark make 3.82 stable two years ago which strongly suggests that breakage was not as severe as people like to portray it.

aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'

Both Microsoft and the Linux kernel go to fairly extreme lengths to preserve compatibility.

They both only preserve binary-level compatibility. They introduce source-level incompatibilities regularly. Not “often” but “regularly”.

According to torquay this means both are “unhealthy cultures” which will collapse soon.

Raymond Chen at Microsoft has a blog that spends a lot of time describing all the nasty hacks it takes to preserve backwards compatibility with Windows applications that access private functions.

This blog contains many amusing tales, but note how it always discusses Windows (or sometimes MS Office) and rarely discussed MSVC or Windows SDK. That's because Microsoft is extremely vigilant with changes to end-user-facing tools but it's not nearly as paranoid when changes are introduced to development tools. If you are using something like resharper or some other addin then you are supposed to keep it updated.

And Linus is famous for his "don't break userspace" rule, even when userspace is doing something that it's not supposed to.

Again: this is a problem if normal program breaks. Source code is kept compileable when it makes sense but if it makes sense to break it then it's done without any remose.

Have you ever considered that part of the reason that Mac OS hasn't been more successful in business is because Apple doesn't have the same strong commitment to backwards compatibility?

Sure. I wrote about it years ago. But again: this only about system ABI, not about developer's tools.

Er, it's open source, isn't it?

Sure. Arduino is open-source, too.

That means the "tarball" is in some ways the primary format of a program, and a DEB or ROM is just a convenience.

Do you want to imply that primary format for the Arduino will be a blueprint and that every user if Arduino should be able to make the PCB and solder the elements to it? This is not how it works: people who want to tinker with design can build various Brasuínos and Freeduinos, but of course, typical user is not supposed to tinker with PCB itself.

As I see it, it is good that a developer can supply the source and not worry about packaging it for N+1 distributions and CPU architectures.

You may argue that it's good in some cosmic sense, but it's primary reason for pitiful 1% desktop penetration of GNU/Linux.

But for this to work, certain basic tools must be have a stable interface.

Right. But the alternative is to provide stable ABI—which is simpler. And people don't even do that. Why do you think they will provide higher-level stable interface if they don't want to do it on the lower level?

It's good to innovate, but if you make an incompatible change, it's effectively a new tool, and don't fool people by keeping the old name and incrementing just a minor version number.

Sorry, but you are wrong: if you don't restrict use of the tool then practically any change will be incompatible change! Especially in a tool like make which can call itself recursively and then retry. Do something like “$(MAKE) foo || $(MAKE) bar” (as I already wrote), implement improper use of some functionality in “$(MAKE) foo”—and voila: your Makefile works with old version of “make” and does not work with a new one.

This was just a minor change because they just added better error message to a case which was always forbidden. The fact that people actually used this erroneous combination is unfortunate, but as always when you use undocumented features you are expected to fix breakage when it changes/disappears.

a claim that »make was never designed or developed with ›unsophisticated users‹ in mind« insults the intelligence of »unsophisticated users« and could just as well apply to other idiosyncratic Unix tools like, say, awk or sed, which are nevertheless just as useful to a general audience.

Nope, they are not useful. Anyone who even knows how to start command-line is a geek from the “Joe Everage” POV. And it's kind of impossible to use awk and/or sed without a command line.

It also purports having an insight into the mind of Stuart Feldman that I do not think you actually command.

The Times They Are a-Changin'. When Stuart Feldman created make “unsophisticated users” were very different and back then use of make was nothing to brag about—but back then people also knew how to fix their Makefiles when they refused to work (they even sometimes fixed their programs when they refused to work!). World was very different back then.

I'm not talking about “unsophisticated users” of 1977 (which lived with Fortran77 compiler made by the very same Stuart Feldman and which was, surprise, surprise, not compatible with Fortran66 compiler!), I'm talking about “unsophisticated users” of today. Make was never intended for these.

No matter how many “regression test suites” you have you still break compatibility regularly. If you introduce some new syntax and/or new “magic” variable then you break something. Heck, if you introduce some new capability you automatically break some things because it's perfectly possible to write “$(MAKE) foo || $(MAKE) bar” in some rule and if “$(MAKE) foo” will start succeeding then everything will blow up (e.g. if it was written in advance to exploit your feature till it's design stabilized but then was not updated when your feature was actually added to “make”).

Now you can start spouting some nonsense like “you are not supposed to support broken code, we are only talking about code which people wrote in accordance to certain rules”, but then you'll lose again because “certain rules” (GNU Make Manual here) never gave you right to write the code which was broken by “make 3.82”!