Re: glib-1.3

[Josh MacDonald <jmacd CS Berkeley EDU>]

Quoting 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.

Why should people have to recompile everything every 2 months?
I don't see it.  Why can't glib-1.3 coexist with glib-1.2?  And
isn't it backward compatible?  This is a serious problem that will
not go away, and as long as it persists it will threaten my desire
to contribute to glib.  This conflict is a serious problem for us,
because we're all working in the same territory and our goals
overlap.  I would like you all to believe that glib is as important
to me and my projects as it is to you and yours, and my projects are
not insignificant.  I resent the fact that I contribute to glib and
have no control over its releases.  I also do not see why eveyrone
complains here.  Will someone please explain why having glib-1.3/4
available will make people using mozilla and gnome-1.0 report bugs 
for that version of glib?  Why can't these programs continue to use
glib-1.2? I do not see why development versions should not be made
available, in fact I don't see any problems at all except for the
soname business.

Collaboration is good, but you are hurting my productivity, and thats
not good for any of us.  There has to be a solution, the current
situation is unacceptable.  I understand your resistance, but do not
consider it sufficient justification.  Glib does not belong to GTK,
it is part of everything, including 60000 lines of my code.  I can't
have Mozilla and Gnome and GTK all affecting my release schedule--that
is unacceptable.  Further, I tested it and Xdelta does depend on the
queues in glib-1.3.  Oh, if only the queue and stack code could have
been added into the 1.2 line, but it was frozen too early (glib shouldn't 
be frozen by GTK!!!  I'm tired of it.).  I may just decide to release
a version of glib named something else, or with a different soname, but 
does it really have to come to that?

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

-josh