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

[Christian Schaller]

On Tue, 2004-03-16 at 00:29 +0100, Scott Wheeler wrote:
> -----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).

GNOME do have such a requirement for libraries in the official library
stack. GStreamer is not in the official library stack atm, instead we
are bundled with GNOME as part of the applications that use GStreamer. 

Personally I don't worry to much over this issue as I think the version
of GStreamer that will be shipping with KDE 4 is the same version that
will be shipped with GNOME 3 both of which I expect in a year+. At which
point we should be able to have something ready that we can live with
keeping ABI stable as David pointed out. At that point I think we also
will move into the official GNOME library stack which gives us the same
pressure from GNOME as you outline from KDE. Which means we will have
strong pressure and motivation to maintain an API stable release series
for a long time after that. And even if we decide to move onto a new
version in say three years from now I think you find people willing to
fix important bugs in the stable branch while waiting for GNOME and KDE
to go for their 4&5, it is not like I expect tons of issues to occur
after 2 years of active use in both GNOME and KDE.

Anyway I hope you and the other KDE multimedia developers will take
GNOME using GStreamer into consideration as a positive point, together
with your other items when making the decision on what to choose.
Personally I think GNOME and KDE using the same library for multimedia
has value in itself and would probably speed up development of
multimedia applications in both communities. 

Christian