Wishes to the new G-Wrap maintainer?
linas at linas.org
Wed Jul 7 21:25:31 EDT 2004
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?
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.)
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
More information about the gnucash-devel