[gst-devel] Doing new releases

[in7y118 at public.uni-hamburg.de]

Quoting Ronald Bultje <rbultje at ronald.bitfreak.net>:

> I've said it before: I'm open for better suggestions. I'm not too happy
> with the lack of active backporting to 0.6.x either. ;).
> 
> However, I just *want* some certainty and control (not specifically by
> me, but just in general) over the stable branch. I want to be sure that
> we don't break API/ABI within one release range. We simply need *some*
> sort of control there. Make proposals on how to do it, but a "everyone
> just go ahead and we'll see where we end up" won't work.
> 
My proposal is simple: Do it like Gnome does. After 0.8 we're API and ABI 
stable, period. (Though this leaves you pretty much room with the plugins 
still.) Don't do big changes to core stuff without asking the others first. But 
commit bugfixes, improvements and write elements all you like.
ALSA, ASF, muxers, ffmpeg, quicktime, subtitles, videocrop, opt fixing, the 
xvideosink deleaking and loads of other stuff could have easily happened on 
stable while we work for 1-2 months only with the stable branch.

And then, when everything works, break API/ABI and rewrite GstThread, 
mimetypes, debugging, tagging and so on.

We'd have ended up with the same HEAD but would have a much more feature-rich 
0.6.


Benjamin