Hacker News Reader

Comment by audidude | Hacker News Reader

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?

View on HN

> 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.

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.

Reply on news.ycombinator.com