Re: Guile release planning

[ludo@gnu.org (Ludovic Courtès)]

Hi Neil!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> OK, it's clear the consensus on 1.8.x is against my suggestion, so
> I'll accept that.  And I can understand the reasons too.  I think
> perhaps it comes down to Ludovic's point about the version number
> being a hint - i.e. people already have expectations about what should
> be in the change from 1.8.x to 1.8.x+1, and mostly those expectations
> seem to be API and ABI compatibility, so it makes sense to comply with
> that.

Yep, it's just a matter of labeling, really.

> For 1.10.0, then, we just need to check that there isn't anything in
> master that isn't ready/working; if there is, it should be moved into
> a branch.

In a similar vein, some of the things developed in the 1.7 series, like
futures, were never stabilized and are simply commented out for now.
Thread support is also somewhat sloppy, as shown my recent reports
(e.g., parallel memoization).  We need to think about these as well.

> And from here on we should adopt the rule that new features
> are always developed on branches, and only merged into master when
> ready and working.  Then we should be able to release master as a new
> 1.y+2.0 whenever we see that enough new features have accumulated.
>
> How does that sound?

Sounds good to me!

Thanks,
Ludo'.