Comment by audidude | Hacker News Reader

Comment by audidude | Hacker News Reader

Parent Full thread

You could have a system that has broken software instead?

But seriously, giving multiple years between the major versions is a lot of time in between for applications to port forward (or they can choose the version they want to stay on) and enough time to stabilize features that take more than 6 months to write. Turns out writing whole new rendering engines takes some time and testing and can't be flipped on as fast as javascript frameworks materialize.

If applications want to stay on a stable version for 5 years or more, that all of a sudden becomes tenable which wasn't the case before unless you wanted to stick to gtk2, which is right out of 1998 "how to write a toolkit".

This isn't very different from other systems that bump the soname and have multiple versions based on what ABI, as required by the applications. I'm sure you have multiple of these on your system already. The reason soname isn't enough for GTK has to do with parallel installability of headers, bindings, etc etc

There is no guarantee that the good software you are using have someone maintaining it or interested in porting it, which is really common in open source word. For me they are Texmacs which only have bug fixes nowadays and a bunch of browser plugins whose producer are not willing in porting them.

The serious problem here is that, What this plan shows is a total lack of concern. Doing rolling release for a distribution is OK, but for a fundamental library this is unacceptable. Qt has been doing much better on this.

FWIW, Qt has been bumping major versions more often than us as well.

It really comes down to ensuring that developers are shipping a known quantity. They should be shipping with a set of libraries that were actually tested.

It's unreasonable to expect the toolkit authors to be able to test every possible permutation on every release unless people stand up to run build bots, automated testing, and report back to us when things break.

Keeping your Texmacs, for example, working in 5+ years time is important to us. That is why we want to give it a stable API that only gets bug fixes after a certain time frame. Is that such a bad idea? Would you really expect to magically get touch, HiDPI support, etc on a 5 year old application when you never changed your application code?

I used to upgrade my Qt 4.x with none issue.

For a fundamental library like this devs should at least keep core api stable for a long time, and release unstable components seperately.

As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch of dependencies.

I believe 5.7 is planned to be an LTS release.

> For a fundamental library like this devs should at least keep core api stable for a long time, and release unstable components seperately.

This is something we'd like to get to (say external widget libraries). But it requires, guess what, an ABI break :)

> As I have stated, I really don't like a large number of similar libraries installed on my machine, each with a bunch o dependencies.

This is a long running "problem" on GNU/Linux. I've been around for a couple of decades and the problem has existed pretty much the entire time. We all have some holy grail of design in how we'd like the world to be and are disappointed it isn't what we think it should clearly be.

I'm not saying your viewpoint isn't valid, just that I'm not sure you can put the necessity to solve it on our shoulders.

As a gentoo user I would say that the ABI break may still worth it if it can enable a lot of application continuing to work with just a recompile, right?

The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break in such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.

> As a gentoo user I would say that the ABI break may still worth it if it can enable a lot of application continuing to work with just a recompile, right?

Yes, just a recompile in all the cases we've really discussed. However, if we can break ABI in minor releases, we have contemplated the idea of installing private headers to allow developers to "do wtf they want" with a I_KNOW_WHAT_IM_DOING #define or something.

But the important thing, is to test the software!

> The controversial around this plan origins from people's inability to understand why such a fundamental library like gtk+ needs to have api break for such a high frequency, which would have a huge impact on the experience of app devs and users? The world has its intrinsic complications, but we all hope to avoid the casual one.

That is the thing. We are a very small team of mostly part time contributors trying to build a toolkit that competes with the big players, who have teams the size of hundreds. There is a lot of work to do, with an insane cadence required.

I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS. They likely are likely breaking subtle things in-between major releases too, but you can either 1) lock to a version or 2) upgrade and fix-the-world.

> But the important thing, is to test the software!

Mandate the world to do test is not a good idea sine the philosophy of the world is to make it work.

>I don't think this isn't really any different than choosing your target device version for say, iOS, Android, or macOS.

No it's not. In case of device only a small bunch of things break. For gtk+ everything breaks without a fix.

> No it's not. In case of device only a small bunch of things break. For gtk+ everything breaks without a fix.

That's because about every other year they have the equivalent of a major ABI break (and they you target explicitly the newer version or stay locked to the old version) and the platform ships both.

This is semantically what we will be providing.

Reply on news.ycombinator.com