[gst-devel] New Year Release-olutions

Jan Schmidt thaytan at noraisin.net
Thu Jan 10 15:27:30 CET 2008

One of my new year's resolutions this year is to be a better maintainer 
and release manager for GStreamer.

To that end, I present a proposal for scheduling releases over the next 
few months - in advance! *gasp*

At this stage, the only part of the proposed schedule that I consider 
rigid is that Core & Base will be freezing for release on the 14th (4 
days from now), and that Good/Bad/Ugly will all see simultaneous release 
after that.

The proposed schedule is here: 

Please, give it a read and let me know if anyone hates it. I expect the 
biggest possible controversy to be over the length of time I'm proposing 

* Executive summary for the lazy:
I'm proposing that this month we do Core/Base releases, then 
Good/Bad/Ugly at the start of February. After that, we move into what 
will be a regular 3 month cycle: Core/Base 1 month, then Good/Bad the 
next, then Ugly/FFmpeg.

I haven't put gst-python in there (it's in a TODO item) yet, but I think 
the best thing to do there, if the gst-python maintainer (Hi Edward!) is 
up for it, is to do gst-python releases in parallel with Core & Base, 
since that's where all the API it's wrapping lives.

Regarding freezes:

Dependency Freeze - I've introduced the idea of a 'dependency freeze', 
which is the period where you're not allowed to make a module depend on 
unreleased versions of anything. When Core/Base are released, the other 
modules enter are dependency frozen and stay that way until they are 
released. In the case of Good/Bad, this will be one month later. For 
Ugly/FFmpeg it will be 2. Another way to put this is that in every 3 
month cycle, there is 2 months in which you *can* add and use new 
Core/Base api in Good/Bad, and 1 month in which you can do it for 
FFmpeg/Ugly. Since everyone will now have plenty of warning about 
exactly when those windows are, I'm hoping that the discipline of when 
to add new API will become easy.

Code Freeze - In the schedule, I have allocated 2 weeks of freeze before 
the release of any module, to ensure there is sufficient time to 
stabilise it before release. I've also got a note that the freeze may be 
shortened to 1 week (at the discretion of the release manager) if the 
module is ready for release earlier than the full 2 weeks.

The other slight wrinkle in the plan, is the option of doing a 2nd Bad 
release simultaneously in the Ugly/FFmpeg release months. The point of 
this is to allow plugin moves between ugly and bad. Such a 2nd bad 
release would only happen if some plugins need moving, and will contain 
exactly the previous bad tarball contents with plugins removed or added. 
This would be ensured by doing any 'plugin move' release of Bad from a 
branch off the previous release tag.

Comments, suggestions and objections welcome!


More information about the gstreamer-devel mailing list