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