GNOME & Intel Developers Plan The Wayland Future

[Krejzi]

And why are you surprised that two major versions of a library are incompatible? Isn't that exactly how it always works?

Yet no one pointed out that same thing happened with Qt3->Qt4->Qt5 (those who are defending it). And no one is complaining because there isn't anything to complain about that. GStreamer 0.10 has been arround for 8 years or so (and I am not sure if ABI/API changed - but I doubt it), it's time for a new design :P

[kigurai]

Yet no one pointed out that same thing happened with Qt3->Qt4->Qt5 (those who are defending it). And no one is complaining because there isn't anything to complain about that. GStreamer 0.10 has been arround for 8 years or so (and I am not sure if ABI/API changed - but I doubt it), it's time for a new design :P

Yeah, I have two versions of Qt installed, just like I have two versions of gstreamer and two versions of Gtk. And libusb, and ... so I have no idea what the problem is.

[Awesomeness]

Can you point out specific breakages? As a user I have not noticed anything.

?The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series.?

http://gstreamer.freedesktop.org/news/#2012-09-24T18:00:00Z

And why are you surprised that two major versions of a library are incompatible? Isn't that exactly how it always works?

Gnome fanboys just defended to use GStreamer directly. Because of that, every single GStreamer-using Gnome app has to be ported manually.
With Phonon no application does even have to be touched. Just select another Phonon back-end and be done.

[kigurai]

?The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series.?

http://gstreamer.freedesktop.org/news/#2012-09-24T18:00:00Z

Gnome fanboys just defended to use GStreamer directly. Because of that, every single GStreamer-using Gnome app has to be ported manually.
With Phonon no application does even have to be touched. Just select another Phonon back-end and be done.

And how is this different from every other major version change of other libraries, for example: Qt3->Qt4->Qt5, Python2 -> Python3, ...?

[TheBlackCat]

And how is this different from every other major version change of other libraries, for example: Qt3->Qt4->Qt5, Python2 -> Python3, ...?

This has already been explained several times.

KDE has a binary compatibility guarantee over the course of a major version (i.e. KDE SC 4.x). Yes, Qt3->Qt4 is a binary-incompatible release, but KDE 3 only support Qt 3, and KDE SC 4 only supports Qt 4. You will never see a KDE SC 4 release that can run on Qt 5 because it wouldn't be binary compatible. Similarly, KDE cannot abandon support for Python 2 bindings over the course of KDE SC 4.x, because again that would not be binary compatible.

Gstreamer, on the other hand, had no such binary compatibility guarantees. Quite the contrary, it was guaranteed to have binary compatibility breaks, although at the time of planning KDE 4 when and how gstreamer was going to break binary compatibility was unknown. Therefore, even if gstreamer's future was guaranteed, which it wasn't at that point, KDE could not, as a matter of long-standing policy, rely on it directly, since it would break their binary compatibility guarantee.

[kigurai]

This has already been explained several times.

KDE has a binary compatibility guarantee over the course of a major version (i.e. KDE SC 4.x). Yes, Qt3->Qt4 is a binary-incompatible release, but KDE 3 only support Qt 3, and KDE SC 4 only supports Qt 4. You will never see a KDE SC 4 release that can run on Qt 5 because it wouldn't be binary compatible. Similarly, KDE cannot abandon support for Python 2 bindings over the course of KDE SC 4.x, because again that would not be binary compatible.

Gstreamer, on the other hand, had no such binary compatibility guarantees. Quite the contrary, it was guaranteed to have binary compatibility breaks, although at the time of planning KDE 4 when and how gstreamer was going to break binary compatibility was unknown. Therefore, even if gstreamer's future was guaranteed, which it wasn't at that point, KDE could not, as a matter of long-standing policy, rely on it directly, since it would break their binary compatibility guarantee.

As far as I can tell the 0.10 series was stable, but not compatible with the earlier 0.8 series. And the same goes for 1.0. If you have other information I'd be happy to see it though.
If you don't, then sorry, I still don't understand why gstreamer is different from say the Qt3->Qt4 shift. Older applications can still use the older version of the library, and everyone is happy (?).

[Awesomeness]

I still don't understand why gstreamer is different from say the Qt3->Qt4 shift.

Yes, it's very evident that you are clueless about that matter and resistant to learn things.

[kigurai]

Yes, it's very evident that you are clueless about that matter and resistant to learn things.

Since I am obviously slow, then perhaps you could share some of your wisdom?

[TheBlackCat]

As far as I can tell the 0.10 series was stable, but not compatible with the earlier 0.8 series. And the same goes for 1.0. If you have other information I'd be happy to see it though.
If you don't, then sorry, I still don't understand why gstreamer is different from say the Qt3->Qt4 shift. Older applications can still use the older version of the library, and everyone is happy (?).

Several reasons:

1. As I explained, the schedule of future ABI breaks was unknown when KDE SC 4 was released. There was no guarantee the 0.10 series would still be readily available over the lifetime of KDE SC 4, nor could KDE developers force Gstreamer developers to keep binary compatibility if they decided to break it multiple times over the course of KDE SC 4.

2. When KDE 4 and phonon were being planned, Gstreamer 0.10 wasn't even out yet.

3. Qt is a core part of a huge number of applications. Continued packaging of it by distros is guaranteed. A multimedia framework like Gstreamer, on the other hand, is much less important so is much less likely to be maintained for a long time. Add to that the fact that Gstreamer wasn't all that popular or well-supported at the time of the KDE 4.0 release (not to mention several years before when it was being planned), assuming that distros would want to continue packaging an unknown number (at the time) of incompatible versions of gstreamer for an unknown (at the time) amount of time. I hopefully don't need to remind you that unlike Qt 3, Gstreamer 0.8 is no longer being packaged by most (if any) distros. If Gstreamer devs had decided to do a 0.12 early in the KDE SC 4 life cycle then 0.10 would probably not be packaged, either.

4. Even if Gstreamer 0.10 continued to be packaged, the libraries it relies on are changing rapidly and breaking binary compatibility much more often than Gstreamer itself is. So without continued maintenance, something like Gstreamer rapidly becomes useless. There are already incompatible releases of Gstreamer dependencies that will never work with Gstreamer 0.10.

5. Gstreamer devs agreed with this approach and promised to write their own Phonon backend. However, around the time KDE 4.0 was released, they changed their minds, said they were completely opposed to Phonon, and never wrote the backend they promised. By then it was way, way, way too late for KDE devs to change their plans.

So yes, by shear coincidence it turned out that the only binary incompatible release of gstreamer happened close to the release of the next binary incompatible release of KDE, and Gstreamer is popular enough that the 0.10 series will likely still be packaged by that point. But there was no reason to think that was the case 5 years ago when KDE 4.0 was released, not to mention 8 or 9 years ago when it was being planned.

[kigurai]

Several reasons:

1. As I explained, the schedule of future ABI breaks was unknown when KDE SC 4 was released. There was no guarantee the 0.10 series would still be readily available over the lifetime of KDE SC 4, nor could KDE developers force Gstreamer developers to keep binary compatibility if they decided to break it multiple times over the course of KDE SC 4.

2. When KDE 4 and phonon were being planned, Gstreamer 0.10 wasn't even out yet.

3. Qt is a core part of a huge number of applications. Continued packaging of it by distros is guaranteed. A multimedia framework like Gstreamer, on the other hand, is much less important so is much less likely to be maintained for a long time. Add to that the fact that Gstreamer wasn't all that popular or well-supported at the time of the KDE 4.0 release (not to mention several years before when it was being planned), assuming that distros would want to continue packaging an unknown number (at the time) of incompatible versions of gstreamer for an unknown (at the time) amount of time. I hopefully don't need to remind you that unlike Qt 3, Gstreamer 0.8 is no longer being packaged by most (if any) distros. If Gstreamer devs had decided to do a 0.12 early in the KDE SC 4 life cycle then 0.10 would probably not be packaged, either.

4. Even if Gstreamer 0.10 continued to be packaged, the libraries it relies on are changing rapidly and breaking binary compatibility much more often than Gstreamer itself is. So without continued maintenance, something like Gstreamer rapidly becomes useless. There are already incompatible releases of Gstreamer dependencies that will never work with Gstreamer 0.10.

5. Gstreamer devs agreed with this approach and promised to write their own Phonon backend. However, around the time KDE 4.0 was released, they changed their minds, said they were completely opposed to Phonon, and never wrote the backend they promised. By then it was way, way, way too late for KDE devs to change their plans.

So yes, by shear coincidence it turned out that the only binary incompatible release of gstreamer happened close to the release of the next binary incompatible release of KDE, and Gstreamer is popular enough that the 0.10 series will likely still be packaged by that point. But there was no reason to think that was the case 5 years ago when KDE 4.0 was released, not to mention 8 or 9 years ago when it was being planned.

Thank you for the explanation.