Re: glib-1.3

[Owen Taylor <otaylor redhat com>]

Josh MacDonald <jmacd@CS.Berkeley.EDU> writes:

> Quoting Josh MacDonald (jmacd@CS.Berkeley.EDU):
> > Quoting Miguel de Icaza (miguel@nuclecu.unam.mx):
> > > 
> > > > 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?
> > > 
> > > I am worried Josh.
> > > 
> > > If people start installing glib 1.3 things you will run into the
> > > problem we have been facing: users that do not use a packaging system
> > > should be real good at configure/prefix or should end up choosing
> > > between GIMP, GNOME or Xdelta.
> 
> To further elaborate, I would like to add that there is a principle involved
> here which I am sticking too.  That is: I am using glib-1.3 for development.
> I don't know if Xdelta works with glib-1.2, and I don't think I should have
> to install glib-1.2 and test it just to be sure.  I know it works with 
> glib-1.3, therefore I should be able to release my code without banging my
> head against a crowd of GTK and GNOME developers. 

OK, this is something I object to.

Until there is a stable, released version of GLib 1.3/1.4 out, people
reporting bugs for:

 GNOME
 GIMP
 Mozilla
 .
 .
 .

with GLib 1.3 will be told to downgrade and try again. If xdelta-1.1
requires an unreleased version of GLib, then a large number
of people will have to stay with xdelta-1.0. I don't know
anything about the xdelta development cycle, but if this
is a problem for you, then you need to test your package
with glib-1.2, as ugly as it is.

And it is not at all hard to keep parallel development environments
to test this stuff.

>  The rest of my prcs2
> code DOES depend on glib-1.3 for sure, so I can't use glib-1.2 for 
> development.  The forced synchronization between glib and everything else 
> is the root of all of these problems.  Perhaps the lack of a decent, 
> functional library dependency mechanism is another cause of the problem.

Maybe GLib doesn't need to wait for GTK+; I certainly am
not committed to keeping the version numbers in sync. But
it seems to me that declaring GLib stable at this point
and releasing is premature.

I am not even using GLib-1.3 yet myself, and don't expect to 
be until GNOME-1.0 is stabilized. I haven't finished fixing
some known bugs with the main loop in GLib-1.2... I don't 
think there even has been full discussion about what people 
want to achieve for GLib-1.3.

That's my opinion; except for the main loop stuff, I'm not a 
major contributor to GLib, so other people's opinions are 
probably more important.

But, for the purposes of GTK+-1.2 and GNOME 1.0, I'm very 
reluctant to declare 1.3 "as good as 1.2". If we are going 
to go with that kind of schedule, then the current method 
of changing the soname for each development cycle is completely 
broken, since people should not have to recompile everything
every 2 months.

For this reason alone, I intend to keep maintaing GLib-1.2
at least until GTK+-1.4 comes out.

Regards,
                                        Owen