Re: api differences between 1.4 and 1.6

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> let's get 1.5.5 out first and see what happens.  i think if we release
> 1.6.x w/o this kind of support documentation, the migration rate from
> 1.4 will be very low (although its adoption rate by newcomers will
> probably be moderate -- until they get burned by some undocumented or
> poorly explained change and leave guile for good, in the process
> spreading the news that guile is improperly maintained and a PITA).
>
> people are unhappy w/ 1.4 release process already (at least i am, which
> explains why i'm doing 1.4.1), the result being some people still stick
> w/ 1.3.4 or only use cvs guile.  repeating the same mistakes is not
> going to help.

Actually, the biggest problem I've run in to is RedHat's library
policies.  They're still on 1.3.4, and from what I've been told it's
because they don't package their libraries in a way that allows
incremental upgrades (i.e. when they switch a major soname, *all*
dependent packages have to be upgraded at the same time).  I'm
planning to try and work this out with the RedHat maintainer after I
overhaul the Debian guile packages (based on what I learn there).
Having to support all the way back to 1.3.4 in gnucash, etc. to
accomodate the RedHat users has been a PITA.

In any case, I sympathize with your position, and if we can get things
documented quickly, then that's fine with me.  I guess right now I'm
just feeling that moving faster, as long as we're still reasonably
careful, may help us a lot.

> btw, an issue has arisen wrt libguile versioning.  guile-1.4 used 9.0.0,
> and it looks like 1.5.x has been using 10.0.0.  i'd like to request
> 1.5.x to use 11.x.x, so that i can release guile-1.4.1 w/ 10.x.x, which
> would be basically the same as 9.0.0, but without the embedded libltdl.
> this would help ease migration a little.

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

> have you been following cvs commits to the HEAD branch?

Not closely lately.

> What do you think of adding devel/build/libguile-versioning-roadmap?
> here's an initial stab:
>
>   version     guile           description
>   6.???               1.3.4           (todo: excavate me)
>   9.0.0               1.4             includes libltdl
>   10.0.0      1.4.x           same as 9.0.0, w/o libltdl
>   11.0.0      1.5.x, 1.6.x    completely new
>
> this is woefully under-detailed and incomplete, and the first thing
> people who use libguile look for (and don't find).  if we can change our
> ways to value and maintain these kinds of documentation, we serve the
> users better and practice good engineering as well.

What's the scope of this documentation, i.e. how does it differ from a
complete NEWS file -- just a summary?  Better yet, is there some other
project that you're thinking of that does this that we could look at
as an example?  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.

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.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD