Re: Stable releases

[Greg Troxel <gdt@ir.bbn.com>]

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