[gst-devel] Required GLib version policy
msmith at xiph.org
Thu Feb 19 19:17:29 CET 2009
On Thu, Feb 19, 2009 at 8:36 AM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> I think we should try to bump our GLib requirements more often. Slowly
> and conservatively, but regularly.
I've argued against this previously, but I think I've been
sufficiently convinced that the burden to users/developers is not
unreasonable, and the benefits sufficient, that this is a good idea.
> To this effect I propose some sort of informal GLib version policy,
> something like:
> - whenever we release core/base, we look into
> bumping the GLib requirement for core/base
> (ie. right *after* the core/base release, not
> for the release itself)
> - we then look at all (stable) GLib 2.N.1 releases
> that are older than ~12 months, and pick the
> highest N. That's our new GLIB_REQ then.
> The overall effect would be that when we release the next core/base the
> required GLib version would be at least around 15-18 months old, which
> seems fair to me (and what I think emerged as acceptable consensus the
> last time we debated this issue on the mailing list).
> - GLib 2.N.1 would be at least 12 months old
> *when we bump the requirement* (at this point
> only affecting GStreamer hackers)
> - a core/base with this new requirement would
> be done ca. 3 months later, so at the time
> this new requirement hits GStreamer consumers
> and distributors the GLib version required
> would be at least 15 months old
> - any GLib 2.N.x series will typically be
> maintained and in use for 6-9 months (random
> info on the side)
I _would_ prefer to see the requirement change a little less
frequently that this, though. Once a year, for example, rather than
twice a year. To give a concrete suggestion then: I'd change your
proposal to do this after every second core/base release.
I'm not going to actively campaign against your plan if you think this
is a bad idea, though.
More information about the gstreamer-devel