4 ms·

> 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

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

stshine 10y ago
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.
audidude 10y ago
> 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.
- stshine 10y ago
  > 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.
  - audidude 10y ago
    > 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.

stshine 10y ago

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.

audidude 10y ago

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

stshine 10y ago
> 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.
- audidude 10y ago
  > 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.