Wishes to the new G-Wrap maintainer?

[Linas Vepstas]

On Wed, Jun 30, 2004 at 12:10:41PM -0400, Derek Atkins was heard to remark:
> > Fixed in 1.9.0 (released today). Unfortunatly, 1.9 and 1.3 wrapsets

Whenever an api changes in an incompatible manner, please bump the 
major version number. That's what major version numbers are for.

In other words, if version numbers were used correctly, then 
a version number such as 1.9 implies that its 100% backwards 
comaptible with 1.3, but that it adds a bunch of new features. 

Sounds to me like you should be calling your thing 'version 2.0'
and not 'version 1.9'.  Although, if we went back to the begining,
and done this correctly, you'd be working on version 6.0 :)

This was one of my major beefs with g-wrap: things like version 1.3.2
not being backwards compat with version 1.3.1 ... who could possibly
guess?  Certainly, no unsuspecting user ...

This is why I like to see smaller packages lumped together:
maintainership duties are shared, and the senior maintainers 
are more likely to catch this kind of bug, before it gets released
into the wild.

> > are incompatible; an 1.3 compatibilty layer or conversion tool is
> > planned, however.

Would be nice ..

> What was wrong with the old interface?!?

I don't think I saw an answer to that ... 

> > 1.9.0 has dropped the GLib binding; it is now provided by guile-gnome,
> > which targets GLib/GTK+ 2. The 1.3/1.4 line is mostly stalled, but I
> > might release a 1.4.0 with a few bugfixes and targetting GLib 2.0, for

If its bug fixes, then call it 1.3.5
If it targets a different version of glib, then call it 2.0.0

> If this is the case we may just pull 1.3.4 into our tree, fix the
> problems that currently exist, and just subsume the code and ignore
> future g-wrap.  

Should have done this a very very long time ago.
We do it for lots of other packages ... why not this? 

Andreas, 
we usually try not to do this, but its a great technique if a package
has a dependency on another packge that is obscure, rare, unmaintined,
etc.  This simplifies things considerably for the distro maintainers
and for the casual user who wants to compile from the tarball or CVS.

If one doesn't do this, one finds that most folks are  left googling 
for non-existant web-sites (such as used to be the case for the g-wrap 
site) or ftp-sites (which is why we have saved old copies of g-wrap 
on the gnucash site, until non-savannah, its not clear it was available 
anywhere else).  This kind of pain makes it less likely that a distro 
will pick up a package, and it hurts the popularity of the app. 

(Some of the larger distro's didn't pick up gnucash until version 1.6,
nearly *5 years* after gnucash-0.9 came out.  I don't know the reason,
but difficulty of building the thing surely played a part.)

--linas




-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933