There is a lot of truth in this but it does take a very lazy attitude to testing.
The simple truth is that if you need your application to support certain distributions, you need to be there on the development releases testing them and either submitting bug reports or improving your application.
And you can automate much of this with a pile of bootable ISOs and a scriptable virtual machine. Testing isn't new.
I release an application "today" (and "today" for example is when Gtk 3.4 is released), and six months down the line the Gtk team decides to release Gtk 3.6 which breaks just about every application that has a GtkTable. As an application developer, I believe I have a right to be pissed.
How do I file a grievance? I go to the GNOME bug tracker to find my bug. CLOSED: WONTFIX - we don't care, our solution is you port to GtkGrid. Doesn't matter to us that you now have to bifurcate your codebase to work with people still running Gtk 3.0 or 3.2, or choose to ship your own built version of Gtk 3.4 with your application. Fuck you, application developer.
What do I do to mitigate the impact? Well, I have to spin an emergency release of my application, despite the fact that no other code might have changed, just because the Gtk team decided that breaking ABI was no longer a concern for them.
Now multiply this for basically every Gtk cycle from 3.4 to 3.1(3/4) and you realize the problem.
I think you're conflating "what's released and out there" with "what's being used or distributed".
I'm saying you can test on the versions distributions are actually shipping (and the ones they're about to be using). In a lot of distributions you can rely on that staying stable for a period of time.
If your application depends on an older GTK library the solution is simple: depend on that version or ship it with your application. This is pretty unusual in the Linux world but old hat for Windows developers where you can only really depend on Win32; and for anything else your installer makes sure it's present.
And finally, for the third time, I'll state that I'm not saying there aren't legitimate issues with how GTK+ is developed. There clearly are... I'm just saying that some of the things Morten wrote show issues in their own development process as much as anything else.
It's not fair to put all the blame on the end developer IMHO.
I mean, in Windows, Microsoft obviously take care not to break binary compatibility - even across several generations of OSes. Right now, in my Windows VM I can run Office 97 on Windows 7 [1].
That's an 18 year old piece of software. And it's still working fine.
I upgrade Ubuntu and it's a flip of a coin whether Google Earth will stop working.
Binary compatibility is noble goal, but when you have the source code to everything it can also be advantageous to just rebuild dependents. The Windows source code contained lots of extra complexity because of its legacy compatibility commitments.
Being mindful of ABI compat, though, is important because rebuilds mean more package downloads for end users and more builds for distros. That doesn't mean we should never, ever rebuild stuff, though.
Can you explain testing actually solves this problem? The problem is multifaceted: it involves the behavior changes of a Gnome, which testing will find, and the unwillingness of some distros (I would imagine Debian is in there) to release new software for reasons other than security fixes, which testing doesn't and cannot address.
The author makes it clear updating his code to fix the problems is not the problem.
That depends what you consider the problem in the scale of things. Needing to fight library versions is a pain but if you know about it (which I'm saying you can) you can do things to ensure your software —your responsibility- keeps working.
Testing helps you find issues before your users start knocking on your door and whining about broken software. They expect you to test. Is that fair? Not even the smallest bit... But it's the way things work.
If you don't give a crap about your users, and you only do this as a programming exercise, let your users be your first line of testing.
Again, I'm not saying that the problems described aren't real (or even that they're not frequent) but if you want to live in an ecosystem, you have to become a part of that. Get stuck in and fix these problems as best you can.
---
And maintaining security-only release structures is designed to make this very problem predictable and maintainable. You know what's going to be in the release a month, two months before it's out. Testing and fixing then means your app works for the life of that release.
The simple truth is that if you need your application to support certain distributions, you need to be there on the development releases testing them and either submitting bug reports or improving your application.
And you can automate much of this with a pile of bootable ISOs and a scriptable virtual machine. Testing isn't new.