Stable releases

Stable releases

[Neil Jerram]

I've been wondering whether we could make stable releases on a more
predictable basis than we have done in the past.

In principle, it seems to me that we should make a new stable release
whenever - and as soon as - we make a fix in one of the stable
branches.  In practice, we might want to temper that a little, by

(a) leaving a short while - say 2-3 days - after committing a fix,
    just in case of a glaring mistake that would be picked up by
    another developer building

(b) postponing a release following one fix if we know that some other
    fixes will be available every soon - to avoid stupidly frequent
    releases.

If we followed this, I'm pretty sure the result would be more frequent
stable releases than in the past.  I don't see any problem with that,
in fact I think it would be a good thing... but then I've never
prepared a release myself.  Is the release process sufficiently easy
and automated that it would allow us to do this?  And what does
everyone else think about whether it's a good idea?

Regards,
     Neil



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

Re: Stable releases

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> If we followed this, I'm pretty sure the result would be more
> frequent stable releases than in the past.  I don't see any problem
> with that, in fact I think it would be a good thing... but then I've
> never prepared a release myself.  Is the release process
> sufficiently easy and automated that it would allow us to do this?
> And what does everyone else think about whether it's a good idea?

I think more frequent stable releases are a good idea, though at least
right now, there is enough by-hand work involved that I wouldn't want
to do it *too* often.  Of course I could probably automate things a
bit more. [1]

Note though, that one thing that is key to making more frequent stable
releases easy is careful discipline on the part of anyone committing
to the stable branch.  If everyone remembers to include the
appropriate ChangeLog, NEWS, etc. entries, then there's much less to
do at release time.  Otherwise, the diff against the last stable
release has to be examined more carefully, developers have to be
prodded, etc.

[1] It might be nice if there were a more automated way to generate
    the html and text NEWS summaries for the web pages and the list
    announcements.  I suppose I could just have the list announcement
    point to the web page, but I don't know how much people like
    having the summary in the message itself.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Neil Jerram]

Rob Browning <rlb@defaultvalue.org> writes:

> I think more frequent stable releases are a good idea, though at least
> right now, there is enough by-hand work involved that I wouldn't want
> to do it *too* often.  Of course I could probably automate things a
> bit more. [1]

I'd like to help if I can with automating things.  Is the release
process documented somewhere so I can begin to get an idea of what's
involved?

> Note though, that one thing that is key to making more frequent stable
> releases easy is careful discipline on the part of anyone committing
> to the stable branch.  If everyone remembers to include the
> appropriate ChangeLog, NEWS, etc. entries, then there's much less to
> do at release time.  Otherwise, the diff against the last stable
> release has to be examined more carefully, developers have to be
> prodded, etc.

Yes, absolutely.  I think a large part of the problem for 1.8.1,
however, was that we weren't sure what the organization and format of
NEWS should be.  Once we're decided on that, I think it would be
easier to put in entries for the diffs.

> [1] It might be nice if there were a more automated way to generate
>     the html and text NEWS summaries for the web pages and the list
>     announcements.  I suppose I could just have the list announcement
>     point to the web page, but I don't know how much people like
>     having the summary in the message itself.

I'm sure we should be able to automate format stuff.  NEWS is in text
anyway, so doesn't this just mean that we need text -> html for the
webpage?

Regards,
     Neil



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

Re: Stable releases

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I'd like to help if I can with automating things.  Is the release
> process documented somewhere so I can begin to get an idea of what's
> involved?

There's some information in workbook/build/release.txt, but I suspect
it may need revision, and perhaps even an overhaul.

> I'm sure we should be able to automate format stuff.  NEWS is in text
> anyway, so doesn't this just mean that we need text -> html for the
> webpage?

It depends on whether we want to include the entire NEWS in the web
and mail announcements, or we want those announcements to be briefer.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Neil Jerram]

Rob Browning <rlb@defaultvalue.org> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I'm sure we should be able to automate format stuff.  NEWS is in text
>> anyway, so doesn't this just mean that we need text -> html for the
>> webpage?
>
> It depends on whether we want to include the entire NEWS in the web
> and mail announcements, or we want those announcements to be briefer.

Personally, I see no problem with having the entire NEWS in both web
and mail.

For the web, that might mean we want two sentences followed by "..."
on the main page, with a link to the whole thing in its own page, but
I'm sure we can automate that.

Regards,
     Neil



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

Re: Stable releases

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I'm sure we should be able to automate format stuff.  NEWS is in text
> anyway, so doesn't this just mean that we need text -> html for the
> webpage?

We might also want to reformat a bit.  I've been manually changing the
NEWS outline format to a list for the web and to an indented plain
text list for mail (see any recent announcement for an example).

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Neil Jerram]

Rob Browning <rlb@defaultvalue.org> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I'm sure we should be able to automate format stuff.  NEWS is in text
>> anyway, so doesn't this just mean that we need text -> html for the
>> webpage?
>
> We might also want to reformat a bit.  I've been manually changing the
> NEWS outline format to a list for the web and to an indented plain
> text list for mail (see any recent announcement for an example).

That's a nice thing to do, but I wouldn't want it to have any weight
in deciding whether we should release more frequently.  (In other
words, I'd be happy to drop doing this if need be.)

Regards,
     Neil



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

Re: Stable releases

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I've been wondering whether we could make stable releases on a more
> predictable basis than we have done in the past.

I'm all in favor of what you propose, but...

> (a) leaving a short while - say 2-3 days - after committing a fix,
>     just in case of a glaring mistake that would be picked up by
>     another developer building

I believe 2-3 days is a bit too short, given the current average
response time on this mailing list.  :-)  So I'd rather say one week.

And also it'd be nice if the release maker could send a reminder one
week before making the release so that people have an incentive to
update their trees and test.

Thanks,
Ludovic.


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

Re: Stable releases

[Rob Browning]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> I believe 2-3 days is a bit too short, given the current average
> response time on this mailing list.  :-) So I'd rather say one week.

In general I tend to agree, but I'd say it probably depends on the
type of change.  i.e. if I look at the diff against the last stable
release, and the only changes are either minor or fairly clearly
correct, then I'd probably feel fairly comfortable creating a new
release without too much delay.

> And also it'd be nice if the release maker could send a reminder one
> week before making the release so that people have an incentive to
> update their trees and test.

If we maintain the stable tree such that we only commit *very*
conservative changes, then the need for wider testing should be
substantially diminished.  However, with 1.8, I think we've been more
liberal (allowing new features, etc.) than we were with 1.6.  Whenever
we're very conservative, the longer advance warning shouldn't be as
necessary, but it shouldn't hurt either.

In any case, assuming I'm going to continue to be the nominal release
manager, then I'd be likely to send advance notifications to the list.
Of course, I don't have to be the only person handling releases,
though there may be some benefit to having one person familiar with
the process coordinating things.

On the other hand, if we make sure that the stable release process is
well documented, and if we make sure to check with each other before
making a release, then we might not really need an official release
manager.  That could help share the work, and avoid a single point of
failure.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Neil Jerram]

Rob Browning <rlb@defaultvalue.org> writes:

> If we maintain the stable tree such that we only commit *very*
> conservative changes, then the need for wider testing should be
> substantially diminished.  However, with 1.8, I think we've been more
> liberal (allowing new features, etc.) than we were with 1.6.  Whenever
> we're very conservative, the longer advance warning shouldn't be as
> necessary, but it shouldn't hurt either.

Agreed.

Because of this discussion, I've been thinking through what we mean by
a stable release, and whether we have taken a wrong turn in deciding
to try to release more stuff earlier by merging from HEAD into 1.8.x.

I think we probably have taken a wrong turn, because I don't think the
1.8.x that we are on the verge of producing can be described any more
as a "stable" series.  Surely the common connotations of "stable" are
that the API is as unchanging as possible, and that the code is only
changed in order to fix non-trivial bugs?

And on the other hand, if 1.8.x isn't a "stable" series, how does it
differ usefully from HEAD?

Therefore, my feeling now is that we should revert to traditional
"stable" handling for 1.8.x.  This would mean not merging enhancements
from HEAD such as my debugging stuff and Ludovic's text collation
work.  It would also mean that Rob's comments about limited testing
requirement hold.

As far as releasing exciting new stuff is concerned, I suggest we just
make unstable 1.9.x releases every now and then.  We should flag these
very clearly as unstable, and not really worry at all about testing
them.

> In any case, assuming I'm going to continue to be the nominal release
> manager, then I'd be likely to send advance notifications to the list.
> Of course, I don't have to be the only person handling releases,
> though there may be some benefit to having one person familiar with
> the process coordinating things.

We certainly need at least one familiar person, but I'm sure it would
be even better to have more than one.

> On the other hand, if we make sure that the stable release process is
> well documented, and if we make sure to check with each other before
> making a release, then we might not really need an official release
> manager.  That could help share the work, and avoid a single point of
> failure.

Yes, I think that would be better.  But we all have a lot to learn
from you first!

Regards,
     Neil



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

Re: Stable releases

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I think we probably have taken a wrong turn, because I don't think
> the 1.8.x that we are on the verge of producing can be described any
> more as a "stable" series.  Surely the common connotations of
> "stable" are that the API is as unchanging as possible, and that the
> code is only changed in order to fix non-trivial bugs?

I think I'd be in favor of fixing trivial bugs too, as long as the
fixes are extremely unlikely to cause any other trouble, but other
than that I agree.

> Therefore, my feeling now is that we should revert to traditional
> "stable" handling for 1.8.x.  This would mean not merging
> enhancements from HEAD such as my debugging stuff and Ludovic's text
> collation work.  It would also mean that Rob's comments about
> limited testing requirement hold.
>
> As far as releasing exciting new stuff is concerned, I suggest we
> just make unstable 1.9.x releases every now and then.  We should
> flag these very clearly as unstable, and not really worry at all
> about testing them.

You have fairly accurately summarized the way I would prefer to handle
things, but it hasn't been completely clear to me that that's what
everyone else wants.

In general I would prefer to be very conservative with the stable
series, and just plan to create a new stable series as often as
needed.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I think we probably have taken a wrong turn, because I don't think the
> 1.8.x that we are on the verge of producing can be described any more
> as a "stable" series.  Surely the common connotations of "stable" are
> that the API is as unchanging as possible, and that the code is only
> changed in order to fix non-trivial bugs?
>
> And on the other hand, if 1.8.x isn't a "stable" series, how does it
> differ usefully from HEAD?

My viewpoint, based on the observation of the current and past release
process, was that HEAD should contain "revolutionary" changes like,
e.g., switching to GMP, providing a replacement to the GH API, and
eventually things like integrating Unicode support, integrating R6RS
library support, changing GCs (?), etc.

Conversely, the "stable" branch would not change such major components.
OTOH, since it may take a while before the unstable branch is usable, I
was happy with the integration of "minor" functionalities such as text
collation into the "stable" series.  But...

> Therefore, my feeling now is that we should revert to traditional
> "stable" handling for 1.8.x.  This would mean not merging enhancements
> from HEAD such as my debugging stuff and Ludovic's text collation
> work.  It would also mean that Rob's comments about limited testing
> requirement hold.

Adding new C code (as is the case with the text collation bug) might
indeed break builds on some platforms.  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.

To summarize: I think we could well have an "in-between" policy, that
is, allowing a little more than just bug fixes in the "stable" branch.
This would require careful evaluation of the problems/breakages that
could be caused by each individual new functionality, and this would
make the release process slightly heavier since more testing would be
required.  I believe many other large software projects (e.g., the Linux
kernel) have a similar policy.

BTW, I haven't (yet?) merged `(ice-9 i18n)' into 1.8.

> We certainly need at least one familiar person, but I'm sure it would
> be even better to have more than one.

Yeah, documenting and automating all this would be very helpful.

Thanks,
Ludovic.


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

Re: Stable releases

[Rob Browning]

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.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Stable releases

[Neil Jerram]

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

Re: Stable releases

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> 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?

I share your concerns about having a really stable series, where new
releases can be made with minimal overhead.

That said, I'm afraid adopting a strict stable policy might have
undesirable side-effects.  In particular, it might be the case that
either users would end up always using the unstable series (because they
don't want to wait for one year to get some new tiny feature), or we
would end up creating new stable series so often that they'd be really
unstable (I think the former is more or less what happens with Debian).

Thanks,
Ludovic.


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

Re: Stable releases

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> I share your concerns about having a really stable series, where new
> releases can be made with minimal overhead.
>
> That said, I'm afraid adopting a strict stable policy might have
> undesirable side-effects.  In particular, it might be the case that
> either users would end up always using the unstable series (because they
> don't want to wait for one year to get some new tiny feature), or we
> would end up creating new stable series so often that they'd be really
> unstable (I think the former is more or less what happens with Debian).

Well we have always had a strict stable policy until very recently, so
there should already be evidence one way or the other.  I don't have
any numbers, but I am pretty sure (anecdotally) that we have had most
users sticking to the stable releases, and a smaller number going
unstable by using either CVS or the nightly snapshots.

That sounds fine to me.  The point is that people know what their
choice means and so set their expectations accordingly.  Under my
proposal - i.e. strict stable policy + unstable releases - the only
thing that would change is that it would be easier for the more
experimental users to get at the unstable code.

If your main concern is getting new stuff out to the users who want to
experiment with it, I would have thought that making unstable releases
would meet that concern.  Does it?  As I asked before: is there some
way that we can specify when or how we would make an unstable release,
that would give you enough confidence about new stuff being made
available?

If we went with your preference - i.e. allowing Scheme-level and
certain C-level enhancements into 1.8.x - I suspect that before long
we would be asked to reinvent the concept of a strictly stable 1.8.1.x
series.  We'd then end up in the same state as I'm proposing, but with
less obvious numbering.

Regards,
     Neil



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

Re: Stable releases

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Well we have always had a strict stable policy until very recently, so
> there should already be evidence one way or the other.  I don't have
> any numbers, but I am pretty sure (anecdotally) that we have had most
> users sticking to the stable releases, and a smaller number going
> unstable by using either CVS or the nightly snapshots.

Good point.

> If your main concern is getting new stuff out to the users who want to
> experiment with it, I would have thought that making unstable releases
> would meet that concern.  Does it?  As I asked before: is there some
> way that we can specify when or how we would make an unstable release,
> that would give you enough confidence about new stuff being made
> available?

Well, I think you're right, this should work well.  But we should
probably produce more unstable releases than for the 1.7 series.  :-)

As for the criteria for making an unstable release, I don't know.  I
guess the main criterion would be convenience.

Thanks,
Ludovic.


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

Re: Stable releases

[Ludovic Courtès]

Hi,

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Adding new C code (as is the case with the text collation bug) might
                                                            ^^^
Oh, I really meant "module" here, really!  :-)

Cheers,
Ludovic.


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

Re: Stable releases

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I've been wondering whether we could make stable releases on a more
>> predictable basis than we have done in the past.
>
> I'm all in favor of what you propose, but...
>
>> (a) leaving a short while - say 2-3 days - after committing a fix,
>>     just in case of a glaring mistake that would be picked up by
>>     another developer building
>
> I believe 2-3 days is a bit too short, given the current average
> response time on this mailing list.  :-)  So I'd rather say one week.

Agreed, one week is better.

> And also it'd be nice if the release maker could send a reminder one
> week before making the release so that people have an incentive to
> update their trees and test.

Yes, good idea.

Regards,
     Neil



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

Re: Stable releases

[Greg Troxel]

[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]


  In principle, it seems to me that we should make a new stable release
  whenever - and as soon as - we make a fix in one of the stable
  branches.  In practice, we might want to temper that a little, by

  (a) leaving a short while - say 2-3 days - after committing a fix,
      just in case of a glaring mistake that would be picked up by
      another developer building

  (b) postponing a release following one fix if we know that some other
      fixes will be available every soon - to avoid stupidly frequent
      releases.

Right now we have stable releases at intervals best measured in years
(0 in 2005, 3 in 2006).  While having them more often would be good,
2-3 days is way too ambitious.  I'd suggest as something that is
achievable and would be useful:

  release 2 months after last release if anything significant has
  changed (where significant means new feature or bug fix)

  release 6 months after last release if anything has changed at all

  release after a 1 week cooling off period if a serious bug is fixed

While newer stable releases are a good thing, having 24 a year isn't.
packaging systems won't keep up, and then won't know which to package.
For pkgsrc, it's really easy to update if there aren't changes to
build procedure or new/deleted files.

In my view, the main path to guile usage by other than the people on
this list is via stale releases and then packaging systems.  This
enables other people to choose to depend on guile.  Currently, that's
a scary choice to make.

-- 
    Greg Troxel <gdt@ir.bbn.com>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

Re: Stable releases

[Neil Jerram]

Greg Troxel <gdt@ir.bbn.com> writes:

> Right now we have stable releases at intervals best measured in years
> (0 in 2005, 3 in 2006).  While having them more often would be good,
> 2-3 days is way too ambitious.  I'd suggest as something that is
> achievable and would be useful:
>
>   release 2 months after last release if anything significant has
>   changed (where significant means new feature or bug fix)
>
>   release 6 months after last release if anything has changed at all
>
>   release after a 1 week cooling off period if a serious bug is fixed

That's fine, but 99% of the time I expect it to collapse in practice
to just the last point, because

- by definition, nothing should usually change in a stable series
  apart from bug fixes

- bug fixes usually happen in response to someone reporting a problem,
  and I find it difficult to imaging saying to that person "we've
  fixed your bug, but don't regard it as important and so will not be
  making a release until a couple of months' time".

> In my view, the main path to guile usage by other than the people on
> this list is via stale releases and then packaging systems.  This
> enables other people to choose to depend on guile.  Currently, that's
> a scary choice to make.

Not sure I understand.  What do you think it is that makes the choice
scary?

Regards,
     Neil



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