Re: api differences between 1.4 and 1.6

[Thien-Thi Nguyen]

   From: Rob Browning <address@hidden>
   Date: Mon, 18 Feb 2002 14:56:38 -0600

   Having to support all the way back to 1.3.4 in gnucash, etc. to
   accomodate the RedHat users has been a PITA.

it is a defensive policy, which is understandable.  outreach can be a
brutal task.

primary to our trust-building sojourn is ability to translate maxim into
published packages, and figure out when to apply "early/often".[1]  this
question's answer tells users how much to trust us.  if the answer shows
lack of method/policy, our way is more difficult in the long run.

hopefully we can express our methods concisely, like in code, or
outlines.  (verbosity in policy is not in the spirit of guile.  ;-)

   I guess right now I'm just feeling that moving faster, as long as
   we're still reasonably careful, may help us a lot.

yes, moving faster is welcome.

   Sounds good.  I'll make that change now (before committing my lib .so
   patches).

i'm not on the version planning committee, but you might consider
jamming 1.5.x starting at 20.x.x to give some room for "migration
releases" (like a safari).  or not.  coddling users is no fun.

   What's the scope of this documentation, i.e. how does it differ from
   a complete NEWS file -- just a summary?

exactly, summarization is the final art when everything else is done.
text-munging scripts, is all it is.

   Better yet, is there some other project that you're thinking of that
   does this that we could look at as an example?

parts of binutils are generated from higher-order templates, e.g.
the c/c++ crowd like doxygen.  etc.

in any case, when we stick w/ sh and scheme we eat our own dogfood (god
what a world), thus exercising guile and attaining a first level of self
awareness.

   Note that whatever we do, we'll need to do for all the .so's in
   guile, since they're all going to be individually versioned as soon
   as I commit my patches.  Given that (and depending on the "scope"
   mentioned above), I'm wondering if we might want a more modular
   approach, handled in the normal documentation.

from guile-tools/scan-api:
# Usage: scan-api guile sofile

(my bad, the awk expression truncates stupidly... will fix rsn)

modules of scripts of modules of scripts ...

i guess i'm trying to say that it's fun to write reflexive tools, why
don't more people do it?

   In particular, as we migrate to having versioned guile modules too
   (not just shared libs), and given how much more dynamic scheme is
   than C, we might want to integrate this kind of change history more
   directly into the API docs.

api docs need only be generated.  writing api docs by hand is so bogus.
there are places for poetry already: the comments and the commentary.
[said in a mad max code warrior voice.]

thi