[gst-devel] Required GLib version policy

[Michael Smith]

On Thu, Feb 19, 2009 at 8:36 AM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:
> Hi,
>
> 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).
>
> So:
>
>  - 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.

Mike