stable branch policy & schedule for 1.8.6

Core developers,

I am honored to announce that I was appointed to the branch manager of
the 1.8 series (ruby_1_8).  With this mail I would like to start my
work as branch manager and release engineer.

First of all, I have to say I am sorry for my lack of presence in the
English speaking community.  To begin with, I will try harder to catch
up with what is going on here, and on ruby-talk, eventually.  However,
I am likely to be flooded by the volume of ruby-talk because I'm a
slow English reader.  So, for important topics which may concern
release engineering of the 1.8 series please feel free to carbon-copy
(CC:) me if I seem irresponsive.

Let me now state my policy as to how to proceed the development of the
1.8 series, and a proposal of the schedule for Ruby 1.8.6.


About the 1.8 branch:

    The 1.8 branch, or in general, a "stable" branch is developed and
    maintained for most casual use by average ruby programmers.
    Besides fixes for security problems and run-time bugs, there can
    be performance improvements, feature enhancements and library
    updates made on the branch.  Those kinds of aggressive changes may
    occur, however, only on condition that backward compatibilities
    and run-time stabilities are retained to a high degree.

    To perform continuous quality assurance and encourage wider use of
    the code base, point releases are issued from the stable branch.
    Each of them is called a stable release and maintained on its own
    release branch where only bug fixes after the release would likely
    take place.

    Note that it is not recommended that you use the cutting edge of a
    stable branch for mission critical use, since a "stable" branch
    may not always be as stable as point releases are.  Use one of
    those point release branches for those purposes.


    The 1.8 branch is planed to be maintained until the third "stable"
    branch (counting from 1.8) starts.


Development of the 1.8 branch:

    Committers are allowed to make a commit on a stable branch without
    explicit approval from the branch manager, as long as it does not
    break any backward compatibilities, that is, it does not delete or
    change any existing features.

    A list of exceptions is as follows.  A commit may break backward
    compatibilities only when:

    - It fixes behavior which contradicts with the document.
      (e.g. a bug fix)

    - It only affects internal, unpublicized interface.
      (e.g. refactoring)

    - It only affects undocumented or undefined behaviors, and
      backward compatibilities that it may break are sufficiently
      considered and reviewed.

    - It is reviewed in public and approved by the branch manager.


    Committers should follow good practices listed as follows:

    - Respect fellow developers and contributors.  Make contact with
      the maintainer(s) when touching a piece of code you do not own.
      When in doubt, ask first.

    - Test your changes before committing them.  Besides running a
      build, it is mandatory to run test scripts, if any.  It is
      always a good idea to add new tests that prove your changes are
      correct.

    - Changes must first go to a development branch, get tested on the
      branch and ported back to stable branches, unless they are not
      applicable to the development branch.  A development branch said
      here is usually the trunk.

    - Related changes must be committed together in a single
      transaction.  Cosmetic changes must be separated from
      functional changes.

    - Keep ChangeLog.  Keep documents in sync with implementation.


    Note that the branch manager can claim any commit to the branch be
    immediately backed out.


Schedule for 1.8.6: (subject to change dynamically)

    2007-02-15 12:00:00 JST
      Declare code freeze

      - The ruby_1_8_6 branch is forked from the ruby_1_8 branch.

      - The ruby_1_8_6 branch is frozen by birth and every commit on
        the branch must be approved by the release engineer (that's
        me).

      (release engineering)

      - The ruby_1_8 branch is not frozen, however, massive changes
        are forbidden for the moment.  This is for every change made
        on the ruby_1_8 branch in this period to be able to get merged
        easily to ruby_1_8_6.

    2007-02-17 18:00:00 JST
      Release 1.8.6-pre1

      (release engineering)

    2007-02-24 18:00:00 JST
      Release 1.8.6-pre2

      (release engineering)

    2007-03-03 18:00:00 JST
      Release 1.8.6
      Lift code freeze


I'm feeling some more clauses should be added, but that's all so far.
All opinions and suggestions are welcome.

Regards,

--
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"Different eyes see different things,
    Different hearts beat on different strings --
       But there are times for you and me when all such things agree"