Re: Replacing Imlib in the GNOME libraries

[Miguel de Icaza <miguel gnu org>]

> I agree 100%. Among other things, ArtPixBuf isn't tested and certainly
> shouldn't be the default code path in the stable branch (I'm not sure it
> should go in stable at all).

ArtPixBuf is very very small.  There is little to test about
ArtPixBuf.  The loaders certainly can use some stress testing as well
as the conversion routines.

> At some point, we need to just branch gnome-libs. There's a lot of work
> that needs to be done to prepare the next version. The next version should
> be source-compatible but much cleaner. 

So far nobody has been able to give me a reason to break backwards
binary compatibility nor a good example that actually would be needed.
People keep telling me "we need a devel branch", and I keep saying
"develop in your branch and once you are ready we merge to HEAD".

So my position on this so far is still: Develop on a branch, and let
me know when you are done to merge it to HEAD.

> We can still do bugfix releases of
> the binary compatible, *stable* version and we can put in a big "don't use
> this" warning for the branch just as Gtk 1.3 does.

Sure, all this hacking can take place, in say GNOME_DEVEL_XXXX
branch.  And that branch can contain that message.

> We don't want to make a big mess out of the stable branch in order to get
> unstable features in it. If we need new features, we need to fork a devel
> version. If we don't need new features and should be focusing on apps,
> then let's not add new features.

I was thinking that all this work would be done in a
GNOME_DEVEL_NUKE_IMLIB branch.

Miguel.