Plan for 2.0

[Neil Jerram]

We're clearly moving towards a 2.0 release.  Here is my attempt to
pull that together a bit and flesh out what needs to be done.

What will go into 2.0:

1. The git "master" branch.  In principle, everything here, but we
need to review and check for

  - anything that should be excluded

  - any applicable fixes that were made in 1.8.x and didn't get copied
to master.

I've started doing this review and will hopefully complete soon.  If
there is anything that shouldn't be in 2.0, I'll move it into a new
branch.  If there are missing fixes from 1.8.x, I'll cherry pick them
into master.

2. The "vm" branch.  Once the review of "master" is done, we'll merge
"vm" into "master".

3. The "ossau-gds-dev" branch.  This contains some minor improvements
to the Emacs interface.  After the review of "master" is done, we'll
merge "ossau-gds-dev" into "master".

4. Any other changes (including bug fixes) that we think are important
to get done before 2.0.  I propose to review the bugs in Savannah, and
also recent email discussions, to identify these.

Is there anything else?  In particular, am I right in thinking that
the BDW-GC work is not ready yet?

One specific query...  Although I advocated removing GH before, I
don't feel 100% confident that that's the right thing for 2.0.  I'm
wondering now if we should instead move the GH code into a separate
library, "libgh", but continue to provide this as part of the Guile
distribution.  Moving the code out of libguile will still achieve the
important objectives of (1) reducing the size of the libguile code
that developers need to look at and work with, and (2) ensuring that
GH is implementable on top of the advertised SCM API; but keeping
libgh in the distribution will be a significant help for users who are
still using GH (who will just need to add -lgh to their link line).

I still think we should remove all GH-related documentation, as we
don't want to do anything to encourage further GH usage.  The GH code
itself is sufficient IMO for showing how someone can migrate their
code from GH to SCM.

That's all for now.  Any concerns or comments?

Regards,
       Neil