From: Akinori MUSHA Date: 2007-01-24T09:55:40+09:00 Subject: stable branch policy & schedule for 1.8.6 --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= =aGrS -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Jan_24_09:55:39_2007-1--