[gst-devel] New Year Release-olutions
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
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.
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