Re: glib-1.3

[Tim Janik <timj gtk org>]

On Wed, 7 Apr 1999, Josh MacDonald wrote:

> I just released Xdelta-1.1.0 and it depends on glib-1.3.0 but there
> is no such publically available glib version.  Would it be possible
> for someone to make a release?
> 
> -josh

i just discussed matters a bit on irc with josh.
he's based xdelta on glib-1.3, because he needs GQueue
and eventually some other newly introduced bits.

while we certainly want to avoid (up to an extend that seems
reasonable) the problems that appeared during the last development
line, e.g. lots of people going bleeding edge and finding themselves
in the need to cover up recently introduced instabilities and
frequently adopt their code to API fluctuations, new contributions
that won't go into the stable line have to be made available and deserve
testing of course.

on the technical side, the matter is: when are the cool development bits
mature enough for public consumption?
- glib needs merging with the stable branch (i'll probbaly do that later
  this day) and could stand some proof reading/testing of the new features/API.
- gtk+, as it currently stands, desperatedly lacks integration of
  the new gdk-win32 stuff (plus the issues mentioned above for glib),
  and will probably take some time until an 1.3.x release.

so while i don't see a reasonably stabelized gtk+ version being released rsn
(similar to owen, i don't even *run* the devel versions yet), this doesn't
neccessarily need to apply to glib, which could imho be braught up to speed
within 2 or 3 days.

whether we *want* to release glib-1.3.0 solely during the next few days, is
a completely different matter, and people tend to differ on that, mainly based
on political issues and practical problems involved.

things raised during ths discussion so far:

- as experience has shown, people will get confused about gtk+/glib
  dependancies and what combination they are supposed to run if they are not
  released in sync. so for one thing, if we release glib-1.3.0 now, we'll have
  to jump gtk+'s version number at some point to release e.g. glib-1.3.1 *and*
  gtk+-1.3.1 together.
- package maintainers will have a hard time getting dependancies right, e.g. a
  devel version of gimp will soon require gtk+1.2.1 and glib-1.2.1 for the gui
  and xdelta-1.1 and glib-1.3.0 for the xd plugin.
- people using glib-1.3 and reporting bugs against glib-based programs (every
  gtk/gnome program, might that be gmc, gnumeric, mozilla, gimp or whatever)
  will be told to downgrade if the program's developer hasn't switched to
  glib-1.3 yet. this point is somewhat moot though, because in any case it
  *will* happen at some point. either now with a glib-1.3.0 release or - say
  in two months after glib-1.3.0 and gtk+-1.3.0 have been released.
  developers are just more likely to have upgraded to the devel lines already
  if glib is released with gtk+ in sync.
- applications based on glib-1.3 (or gtk+-1.3 for that matter) cannot be
  considered stable, until a new stable branch has been created, i.e. 1.4.
  that's simply something app developers have to be aware of, so if they want
  stable products, develop against 1.2.
- contributions to glib can not be taken advantage of until there's a (new)
  development release out there, incorporating them. autoconf plus conditional
  compilation of extra sources is one way to get around that, but it tends to
  be a temporary solution and gets more and more hairy over time (the
  GTK_HAVE_FEATURES* mess in old gnome and gtk program versions is one of the
  best examples for this).
  thus, developers all so frequently doubt the worth of the extra hassle and
  prefer to defer releases of their own projects, require newer releases of
  the dependant packages and with that cause their users to go bleeding edge.


while lots of these problems are actually not glib/gtk or gnome specific, but
can be observed in other software territories as well, they tend to emerge for
these project due to the active development and permanent feature tracking.

there's no perfect solution to this, but we should do our best to lessen the
burden on all parties. i personally would like to urge josh to not base
xdelta-1.1 on glib-1.3 at this point (especially due to miguel's intentions
to base *stable* bonobo on librepo) and give glib (and eventually gtk+) some
more room to get mature.
on the other hand, if gtk+ continues to lack integration on the gdk part like
it currently does (and fluctuate API wise, though that shouldn't be as much an
issue as it has been during the 1.1.x versions), and the additions to glib are
overseingly stabelized (especially regarding the API), we should decide on
either releasing new glib devel versions solely for a while or start back
merging of those additions into the stable branch.

---
ciaoTJ