The kernel actually patched around that, so kernel developers aren't actually stuck. It's true that older kernels won't build with current make though. I think I remember noticing that Fedora carries a patch that fixes this issue, but am too lazy to check. It's possible other distros do too.
FWIW: Other issues with 3.82 broke things in Android and openembedded too. It wasn't their finest release.
When will developers start to understand that backwards compatibility is one of the most important goals of any software system? Randomly introducing something that is backwards incompatible in a minor point release is simply unacceptable.
A huge amount of complexity in using and deploying software comes about because of very narrow version requirements, where due to combinations of backwards incompatibility and necessary new features, there are very narrow windows of software which is actually usable. Add in dozens of different packages, and you are frequently left with a situation in which there is no single set that will all interoperate.
The Linux kernel has a very reasonable attitude: you don't break userspace. You just don't do it. I wish more tools would adopt this attitude. You just don't break your API, ever. No backwards-incompatible revisions, ever. If it's backwards incompatible, it's a new piece of software, not an update.
I realize that this is fairly idealistic, but having experienced so much breakage with non-backwards compatible software, and had so much better experience any time people make an actual honest effort to preserve backwards compatibility, I really hope that more developers start to consider backwards compatibility one of their primary goals, only to be broken if absolutely necessary, and only with a major version change or entire renaming of the package.
Actually GNU make is not a good target. Historically make has been extremely careful about backwards compatibility. The "bug" here is that the Makefiles were relying on an undocumented feature.
In general yes it'd be good if developers paid more attention to backwards compatibility.
Sure, they were relying on an undocumented feature, but it's not like the GNU Make developers didn't know about this. They explicitly called out the backwards incompatible change in the release note; they knew they were breaking compatibility.
My point is that even undocumented features are an important part of backwards compatibility. If there is software out there relying on it, breaking it and saying "well, they were relying on an undocumented feature" doesn't actually help your users at all. Is your goal to ensure that developers do everything the way you tell them to all the time, and punish them if they don't? Or is your goal to provide software that your users can use to do their jobs?
I disagree, when using undocumented features, the burden is fully on the developer using these features.
It is how the world works, when you use undocumented features in every aspect of life (e.g. not following the rules) it is great when you get away with that, but don't expect the world to bend their rules to accommodate you, that only happens when a majority goes that path, and often it doesn't even happen then.
No, how the world works is that you satisfy your users or your users go someplace else.
Microsoft gets this. Linus gets this. FSF and GNU, while I love their ideals, are apparently a bit too ivory tower to actually get it on things like this.
In theory that sounds great, but as we've seen with make, the end result is that the users of make just didn't upgrade. If that's not a desirable outcome for you, then it's on you to prevent that. No else is going to.
Which change are you referring to? Excluding outright bugs, there were no undocumented features that changed in 3.82.
There were several outright bugs; without a patch (that most distros apply), it would SIGABRT during the Android build, perhaps this is what a few people are referring to (I am unaware if this was the only problem with building Android on 3.82)
The most significant backwards-incompatible change was changing how pattern rules are selected if there are multiple matches, but this is documented.
Perhaps you are thinking of wildcard expansion, which has the undocumented feature of returning a sorted list? That wasn't actually changed, it was marked as a "Future backward incompatibility" that would be changed in the next release.
I can't help but think that this approach is similar to Microsoft's, and appears to have led to stagnation. It must have some upsides for developers, but I'm not sure is a winning strategy in the long run.
> I think I remember noticing that Fedora carries a patch that fixes this issue, but am too lazy to check. It's possible other distros do too.
Doesn't look like it; I checked the Fedora sources for their make package, at http://pkgs.fedoraproject.org/cgit/make.git/tree/ , and none of the patches appears to affect that backward-incompatibility.
If anyone knows of a patch, in a Linux distribution or otherwise, which fixes this backward incompatibility, I'd love to hear about it.
FWIW: Other issues with 3.82 broke things in Android and openembedded too. It wasn't their finest release.