future of ABIs (was Re: [gst-devel] amarok)

Scott Wheeler wheeler at kde.org
Mon Mar 15 15:30:03 CET 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- -Scott

- -- 
The three chief virtues of a programmer are: laziness, impatience and hubris.
- --Larry Wall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAVjxMQu0ByfY5QTkRAsZLAJ452z31M/JIlmdkmoKNXQ3Fzmzx0QCgr8PQ
28+oZKTxFr0/NncCVgFSsRA=
=tKVl
-----END PGP SIGNATURE-----




More information about the gstreamer-devel mailing list