You’re talking about two different kinds of stability. They are talking about development stability. You are talking about runtime stability.

One thing is to not break applications that use your library because of changes you introduce to it. Specifically changes that go against the standard you’re supposed to be following.

Another thing altogether is to not go outside the memory limits of the application so it doesn’t get yeeted by the kernel.

I’ve had growing pains for KDE on Wayland in the past but it’s been chill in recent times too, I can’t remember having any issue related to that for a long time

Linus Torvalds is author and maintainer of one of the most successful pieces of software ever written ( software that is decades old and still growing in popularity ).

What does Linus says about your philosophy that “Sometimes you do need major changes that break stuff to upgrade the base”? I think his first sentence explains where he stands but he expands on his initial point.

https://lkml.org/lkml/2012/12/23/75

Implementing old standards does not magically result in unstable software. I can create software today that implements decades old standards using whatever whiz-bang tech is in vogue.

I do lot accept that “old bases” have to succumb to any of the things you suggest either. Refactoring is a thing. You can remove dead code, you can adopt new patterns, you make code modular, you can even extend using new tech if you want.

Linux is 30 years old ( the basic design is decades older ). Should we throw it out? I vote no but allowing Rust into the kernel seems like a good idea. How old is GCC? How old is Microsoft Office? How old is Firefox? This is software you may use every day. Trust me, your life relies on software that is much, much older. How often do you think they rewrite air traffic control systems or core financial software to to make it more “stable” as you suggest?

I mostly hear your argument when devs want to try new tech and cannot justify it any other way. Most often the result is something that is far buggier and missing many features. By the time the features return, the new code is at least as bloated as the original. Around then, somebody usually suggests a total rewrite.

Old architectures are a different story. Sometimes things are not worth fixing in place. In my experience though, this is fairly rare. Even then, in-place migration to something else often makes more sense.

In my view, if you cannot modernize an old code base, it is a skills issue.

In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.

That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.

GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.