Re: Branching for 1.8 on 2006-02-05

[Marius Vollmer]

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Rob Browning <address@hidden> writes:
>
>> Also if we don't want to have people hold off on 1.9 only bits in the
>> trunk, then I'd say that now qualifies as "as late as possible" ;>
>
> There has been no 1.7.3, the CVS repository has been relatively
> quiet since 1.7.2, and applying patches has sometimes been, well,
> delayed.  Therefore, I find it quite strange to branch in this
> moment of quietness and uncertainty.

I unfortunately can't find the time and/or concentration to do more
significant work on Guile right now.  I have been wanting to make the
1.8 release for quite some time now, and it has become clear to me
that I need to stop procrastinating and to start giving myself some
strict deadlines if I want to make any progress at all.

The trunk is featurewise in a good shape for a release, and one point
of the branching is to actually remove uncertainty: it should be much
easier now to work freely on new things in the trunk; you don't have
to worry to mess up the 1.8 release.

> Also, it seems that there is no clear plan for the eventual integration
> of Unicode and to me, having at least a rough plan would be a
> prerequisite to the next stable release.

There is a rough plan.  The new C-side array API in 1.8 is the
beginning of it and the (my) plan is to redo the underlying
implementation in a cleaner way and add uniform arrays of 8-bit,
16-bit, and 32-bit Unicode code points in the process.  Then the
srfi-13 and srfi-14 functions will be extended to cover all of Unicode
and there will be scm_from_utf8_string functions, etc.  This means
that strings remain vector-like.  (If experience with that shows that
a more efficient representation for non-8-bit code points is needed,
we can start experimenting with it.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405