Project

General

Profile

=begin
= Ruby 1.8 Branch Policy

== 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 all of the following conditions are met:

  • It only affects:

    1. behaviors which contradicts with the document,
    2. internal, unpublicized interface,
    3. undocumented features,
    4. undefined behaviors,
      or
    5. presumable misuses.

  • The new behavior will not change again in nor contradict with
    the next major version series of Ruby.

  • If it is assumed that it may silently affect existing code in
    a subtle way, sufficient information and/or a support tool must
    be supplied with to help users fix their existing code.

  • It is well considered and reviewed in public and approved by
    the branch manager.

  • It is well documented and announced in ChangeLog and NEWS as
    soon as it goes in.

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.
=end

Like0