[gst-devel] Required GLib version policy

[Tim-Philipp Müller]

On Thu, 2009-02-19 at 17:51 +0100, Farkas Levente wrote:

> why would you like to bump requirements version when even an older glib
> can work properly? most enterprise distro has very old (in this sense)
> glib, but gstreamer can work even with that version. eg rhel/centos-5
> has only glib2-2.12.3. even with that version all of the latest
> gstreamer can work. but if you bump version (without any good reason)
> we've to hack the tarball to be able to compile the latest versions on
> enterprise distros.
> so i vote against it.

So we can make use of all the new stuff that gets added to GLib at some
point (obviously); because it makes life easier for developers if we
can. It also decreases the divergence between a) the GLib version 99.9%
of the users use [the people who install Fedora/ubuntu/debian and just
use the version shipped with it] and that 99.9% of the GStreamer hackers
use, and b) the minimum version that's required. This has many
advantages, not least of them for debugging/bug triaging etc.

Other than features, there are a bunch of GObject thread-safety issues
which we can't work around fully in GStremaer and which are only fixed
in later glib versions than 2.12. Just as an example.

And: so we don't have to have this argument about whether the ability to
make use of some specific feature in glib is worth bumping the
requirement for all the time over and over again.

At the end of the day it's a trade-off between maintenance ease/burden
and convenience for consumers of GStreamer such as yourself. Following
your line of argument (it works now just fine), there'll never be a
really good reason.

There are very very few people that feel like they need to run a
bleeding edge GStreamer on top of a REALLY OLD distro release (I think
it's fair to say that something older than 18 months is really old in
open source land). Why can't you either (a) upgrade to a newer GLib
[hardly something that is likely to screw up your entire system], or (b)
build your bleeding edge GStreamer against a newer GLib in a non-system
prefix? These seem perfectly acceptable technical solutions to me, and
it seems to me like the only reason you're not in favour of my
suggestion is that it would inconvenience you.

Put differently (in good advocatus diaboli spirit): why should we/I care
about something that inconveniences you / a small fraction of our end
user base, but doesn't really pose any problems for you that can't be
overcome? When it could make my/our life easier?

Cheers
 -Tim