Re: Stable releases

[Neil Jerram <neil@ossau.uklinux.net>]

Rob Browning <rlb@defaultvalue.org> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Adding new C code (as is the case with the text collation bug) might
>> indeed break builds on some platforms.
>
> Yes.
>
> Also, for anyone who might not be thinking about it, it's probably
> worth keeping in mind that Guile builds on quite a few architectures,
> and our current release policy attempts to account for that by calling
> for the heaviest testing during the unstable to stable transitions (to
> hopefully catch any bugs related to endianness, pointer size,
> etc. that haven't been caught during the unstable development
> process).
>
> The assumption has been that any changes during a stable series will
> be be well enough controlled that they won't be nearly as likely to
> need that broader testing.
>
>> If this is the case, then it may be the case that the series can
>> hardly be regarded as "stable".  Adding new Scheme modules, however,
>> is unlikely to break builds.
>
> I agree that it's certainly less likely, but here are some things we
> might want to consider:
>
>   - This policy would raise a somewhat arbitrary
>     implementation-related criteria for the addition of new features,
>     i.e. "If you can write it in Scheme only, then it can go in,
>     otherwise it has to wait."
>
>   - Any added modules probably won't have been nearly as broadly
>     tested as the rest of the modules in the tree.
>
>   - A given stable release series would no longer map to a known and
>     consistent set of features.  i.e. One wouldn't be able to say with
>     certainty that 1.8 doesn't have SRFI-N.

I share Rob's concerns.  For me, the two goals that seem important
are

(1) avoiding the risk of unintentional changes during a stable series
    - which I see as breaking the implied "contract" that we have with
    our users, and

(2) being able to make a new, reliable release, within a stable
    series, without requiring a lot of new testing - because when we
    know we've fixed a bug, we want to be able to get the fix out
    there with a minimum of further work.

>From a purely pragmatic point of view, the easiest way of achieving
these goals seems to me to be to adopt a bug fixes only policy.  I
would even prefer not to bother with documentation enhancements in the
stable series.

I also appreciate Ludovic's wish to get new stuff out into the open
more quickly, and I'm pretty sure that Kevin would take that view too.
Therefore I'm wondering if we can balance the above strict policy on
stable releases with a plan for making regular releases of HEAD.
These releases should be clearly flagged as "alpha", "experimental",
"technology preview" and so on, but would allow interested people to
see, try out and contribute to what's new - which would ultimately
then help us to get to a new stable series containing the new features
more quickly.

We can also review when and how we decide to go to a new stable
series.  Personally I have no clue what our current criteria are here,
and my only thought at the moment is that we need some minimum
interval between stable series - of the order of 1 year - because the
overhead in preparing and pre-release testing of a new stable series
is quite substantial.  Perhaps we should go for regular timed
releases, like Gnome, with feature freezes and stuff.

To summarize, and to get back to my stable release question, what I'd
like to know is - for all active developers - is there some plan for
getting future stuff out (by a combination of (a) experimental HEAD
releases and (b) how we decide when to start a new stable series) that
would make everyone happy to accept a strict bug fixes only policy for
existing stable series?

Please let me know what you think!

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel