svn commit: r619996 - /httpcomponents/project/src/site/apt/bylaws.apt

[ro...@apache.org]

Author: rolandw
Date: Fri Feb  8 12:45:56 2008
New Revision: 619996

URL: http://svn.apache.org/viewvc?rev=619996&view=rev
Log:
added sections on Release Labels and Code Review

Modified:
    httpcomponents/project/src/site/apt/bylaws.apt

Modified: httpcomponents/project/src/site/apt/bylaws.apt
URL: http://svn.apache.org/viewvc/httpcomponents/project/src/site/apt/bylaws.apt?rev=619996&r1=619995&r2=619996&view=diff
==============================================================================
--- httpcomponents/project/src/site/apt/bylaws.apt (original)
+++ httpcomponents/project/src/site/apt/bylaws.apt Fri Feb  8 12:45:56 2008
@@ -237,5 +237,110 @@
 
 
 
+Release Labels
 
+  We use version numbers with two or three digits and labels
+  <alpha>, <beta>, <RC>. The version numbers are used as follows:
+
+   * 4.0 - a major version.
+     Major versions include significant API changes and enhancements.
+     They should be expected to be incompatible with previous versions.
+
+   * 4.1 - a minor version.
+     Minor versions include compatible enhancements, but can also include
+     minor API changes. While we try to maintain API compatibility for
+     minor versions, there may be cases where we prefer to fix a problem
+     in the API by implementing an incompatible change.
+
+   * 4.0.1 - a bugfix release.
+     Bugfix releases are compatible with the respective major or minor version.
+
+  Development of major and minor versions typically passes through the
+  following phases:
+
+   * <alpha> - API is instable, functionality untested
+
+   * <beta>  - API is stable, test coverage improving
+
+   * <RC>    - API is stable, test coverage good
+
+   * <final> - no significant bugs uncovered since last RC
+
+  In the alpha phase, functionality is implemented and the API drafted.
+  When the API has stabilized and covers the intended functionality for
+  the next major or minor version, the API is frozen and development
+  moves to the beta phase.
+
+  In the beta phase, the implementation is stabilized by improving the
+  test coverage and refining the API specification. Compatible API changes
+  are still expected. If significant problems with the API are uncovered,
+  incompatible changes can be introduced with a deprecation cycle. That
+  means that there is at least one compatible beta release in which parts
+  of the API are marked as deprecated. The deprecated parts of the API can
+  then be removed in a subsequent release.
+
+  The RC (release candidate) phase starts when the developers consider the
+  codebase stable and mature. The API is kept stable, even compatible
+  enhancements will be minimized. Activity during the RC phase is focused
+  on improving the documentation and test coverage. If some major or
+  many minor bugs are detected, these are fixed in a new RC release.
+
+  The final release of a major or minor version is published if bug reports
+  for the RC releases are ebbing away. While the previous releases include
+  the alpha, beta, or RC label in their name, a final release is published
+  with the two digit version number without a suffix.
+  The final release is moved to a branch in the source repository for
+  maintenance. Bugs are fixed for that version in compatible bugfix releases
+  off the branch. Issues that require an API change can only be addressed
+  in the next minor or major version, which is developed on the trunk.
+
+
+
+Code Review
+
+  The two styles for code review at Apache are review-then-commit (RTC)
+  and commit-then-review (CTR). Not only the program code is reviewed,
+  but also the contents of the website and the Wiki. 
+
+  With RTC, a patch is published in the issue tracker, then reviewed by
+  the developers, and committed to the source repository only afterwards.
+  Lazy consensus is sufficient, there is no need for formal voting or
+  three opinions in favor.
+
+  With CTR, a change is committed to the source repository directly.
+  Developers receive the change notification on the commits mailing list
+  and review the repository contents.
+  If there is a major problem with the change, any committer can veto the
+  change by sending a -1 reply to the commit message. After a veto, the
+  change is reverted as soon as possible in the source repository and the
+  reason for the veto will be discussed.
+  Minor problems are not handled with a veto and revert, but by discussion
+  on the mailing list and followup patches.
+  
+  We use both RTC and CTR, and common sense to decide between the two.
+  Some simple rules are:
+
+   * changes to Charter and Bylaws are RTC and require formal PMC approval
+
+   * updates to the Wiki are CTR
+
+   * code contributions by non-committers are RTC
+
+   * simple bug fixes are CTR
+
+   * documentation improvements are CTR
+
+   * updates to the website are CTR
+
+   * code changes in an unstable development phase are CTR.
+     Unstable phases are <alpha> for all changes and
+     <beta> if the API remains compatible.
+
+   * major code changes in a stable development phase are RTC.
+     Stable phases are <beta> for the API, <RC> for all the code,
+     and maintenance in the branch of a final release.
+
+   * committers looking for feedback on an idea use RTC
+
+   * changes to an experimental branch or sandbox are CTR