future of ABIs (was Re: [gst-devel] amarok)
wheeler at kde.org
Mon Mar 15 15:30:03 CET 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 16 March 2004 0:09, David Schleef wrote:
> What is a major release cycle? 3.2->3.3, or 3.0->4.0? If it's
> the latter, I don't think there's much possibility in GStreamer
> actively maintaining the stable branch that would be used in 4.0
> until 5.0 comes out.
It's the latter.
> That could be potentially be several years.
> Given the current state of multimedia frameworks, I don't think
> it's wise to even _want_ a stable ABI for that long.
Yes, it would be years. It looks like the time from KDE 3.0 -> KDE 4.0 that
will be roughly of 3 years. Both KDE and GNOME regularly keep ABI stability
for that time frame.
aRts -- for all of its faults has kept a stable ABI since KDE 2.0. (And
during some of that time development actually was active.)
> That being said, I hope GStreamer in 1 year is in the state where
> we can be comfortable with a long-term ABI.
Well, we're probably 15-18 months from a KDE 4.0 release.
I guess there are a few notes here -- first, this *is* very important and does
take a long term commitment from the folks here. This doesn't mean that the
current version has to stay with the same API for three years, but it does
mean that KDE will stick with a single API throughout a major release time
frame and there is the expectation that said release will be maintained.
"Fixed in HEAD, but it doesn't matter for you for 2 years..." won't work.
I've seen debates on this for Gst before. But I'm really surprised that GNOME
doesn't have similar requirements for the 2.x series (though I would guess
that GNOME 3 is significantly closer than KDE 5). My personal experience
with APIs is that sticking to an API can be annoying, but that it forces a
certain shift in mindset that brings about code maturity (when all of the
sudden you can't just redesign because you did the last iteration on a whim
and got it wrong). Sometimes living with mistakes (and realizing that you'll
have to) can really help.
This decision of course isn't up to me, but it will be an important factor in
KDE or other large projects' adoption of GStreamer.
The three chief virtues of a programmer are: laziness, impatience and hubris.
- --Larry Wall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the gstreamer-devel