--pgp-sign-Multipart_Wed_Jan_24_09:55:39_2007-1
Content-Type: text/plain; charset=US-ASCII
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"
--pgp-sign-Multipart_Wed_Jan_24_09:55:39_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQBFtq6Lkgvvx5/Z4e4RAmreAKCKjIE7cZAjiODUt1SK3b86y8HvlwCgtA9A
bZ2Vsw3044CJ99vtlvZ0m38 ¨Â-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Wed_Jan_24_09:55:39_2007-1--