On Mon, Sep 17, 2001 at 06:14:20PM -0500, Derek Neighbors was heard to remark:
> > Well, there's no practical way of doing this. Take, for example,
> > printing. We can support printing simply & easily by using gnome-print.
> > Or we can try to implement it on our own, using a bizarre hack
> > involving latex, sgml, ghostscript and what-not that would have been
> > difficult and a hack job.
>
> So you are saying every feature or buglet squished had to do with a new
> dependency? I think I was misunderstood here. Of course features that
> are dependent on new dependencies can not be put in the current version,
> but bug fixes, and not dependent features could be.
Well, yes ... We started working on gnucash 1.5.0 at the time that 1.4.1
came out, and we got up to 1.4.12 before gnucash 1.6.0 came out...
that represents eleven releases of bug fixes in the stable tree while
we were adding new features to the unstable tree.
Normally, you don't add 'new features' to a stable branch.
Say, for example, I've got some really cool new feature ... should
I add it to gnucash-1.6.3? What about the poor slob who thought
that an upgrade from 1.6.2 to 1.6.3 would fix the bug that's haunting
him, and instead discovers that 1.6.3 was a major rearrangement of
internal organs, and covered with open wounds and sores? I don't
think that would go over very well.
So then you have to argue that we should have three trees:
the stable 1.6.x series, with only bug fixes, the experimental 1.7.x
series, with new features that don't link new libraries, and a 2.x
series that has new external dependencies.
It would be too much. A bug fix would need to get checked in, (*and
tested*** i.e. built, compiled, run, yuck) in three trees. Two is
bad enough.
And new features tend to tear up the guts, and so the 1.7.x and the
2.1.x trees would rapidly diverge, and now the programmer has to add
a new feature to two rather different trees? yuck.
e.g. I made some SQL performance enhancements to the gnucash-1.7 tree.
I started to back-port these to the 1.6 tree, and gave up after I
realized it was more than a few evenings worth of work. There are
such significant structural changes between 1.7 and 1.6 that such a
backport would require considerable concentration and patience and
care.
Now, the internal API's in gnucash 1.6 and 1.7 are the same, so the
code is still 'modular'. My code, however, mucks in the middle of the
module, where there are large differences. I can't just make a patch
file, and apply it.
So its theortically possible, but practically speaking, no one ever
develops code in that way.
--linas
p.s. However, you are right in another way, and perhaps we goofed.
When we added graphing and print support, we might have done
some kind of #ifdef HAVE_PRINTING so that maybe we could create
binaries with fewer library dpendencies (and fewer features). But ...
does that mean we should have two or three times as many installable
binaries? a 'gnucash-minimal' binary, with major dependecies ifdef'ed
out, and another, with everything turned on? Almost nobody does this.
The final choice is to use dynamcially loaded extensions. Already do
this with the potgress backend. Gnucash binaries compiled --with-sql
will run just fine on machines without postgres, because its just a dll.
I beleive that the other coders are restructuring gnucash-1.7 to have
this kind of a dynamcially loaded plug-in system. This way, if feature
whiz-bang is a plug-in, and the required supporting libraries aren't
installed, then the plug-in simply won't run. Of course, if you want
all the plugins to work, you'll still need to install/upgrade like crazy
...
PGP signature
