Wishes to the new G-Wrap maintainer?

Andreas Rottmann a.rottmann at gmx.at
Fri Jul 9 12:15:35 EDT 2004


linas at linas.org (Linas Vepstas) writes:

> 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.
>
Sorry, but there is no "standard scheme" for version numbers everyone
must adhere to. I prefer to use minor version number as "branch
indicator" (like the Linux kernel, GNOME, ...). Branches may break
API. Major version numbers are bumped for re-writes and the like
(i.e. big internal changes, huge milestone reached, etc).

> 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. 
>
See above.

> 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 :)
>
It will be named 2.0 when it has become stable (1.3.x, 1.9.x:
unstable/development branches, like Linux 2.3/2.5).

> 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 ...
>
OK, I can promise you that during a stable series (upcoming 1.4 and
2.0 series), there will be no compat breakage. Compat may be broken
across series (e.g. 1.3 -> 1.9) on the development branch.

>> > 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 ... 
>
Well, since the whole core of G-Wrap has seen a rewrite, also the old
API (which more or less is an expression of the core structure) was
naturally replaced by a new one. If you are interested in why I did
the rewrite and what goals it pursuits at
http://www.nongnu.org/g-wrap/TheNextGeneration.html.

>> > 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
>
See above (Linux versioning scheme). I will call it 1.4.0, since it
will be the start of a stable series.

> If it targets a different version of glib, then call it 2.0.0
>
Good point. Best would probably be to have 1.4.0 support both GLib 1.2
and 2.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.
>
Yeah, I understand why you consider pulling G-Wrap in, but I intend to
change its "obscure, rare, unmaintined, etc." status ;-)

> 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. 
>
Yeah, but G-Wrap has a homepage and its own file release area now.

Andy
-- 
Andreas Rottmann         | Rotty at ICQ      | 118634484 at ICQ | a.rottmann at gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux



More information about the gnucash-devel mailing list