[svn-commits] russell: branch russell/project_docs r161825 - /team/russell/project_docs/inc...

[SVN commits to the Digium repositories]

Author: russell
Date: Mon Dec  8 14:08:40 2008
New Revision: 161825

URL: http://svn.digium.com/view/asterisk?view=rev&rev=161825
Log:
commit progress ...

Modified:
    team/russell/project_docs/include/asterisk/doxyref.h

Modified: team/russell/project_docs/include/asterisk/doxyref.h
URL: http://svn.digium.com/view/asterisk/team/russell/project_docs/include/asterisk/doxyref.h?view=diff&rev=161825&r1=161824&r2=161825
==============================================================================
--- team/russell/project_docs/include/asterisk/doxyref.h (original)
+++ team/russell/project_docs/include/asterisk/doxyref.h Mon Dec  8 14:08:40 2008
@@ -185,24 +185,19 @@
  *
  * \section ast10policy Asterisk 1.0
  *
- * \subsection ast10releases Release Policy
+ * \subsection ast10releases Release and Commit Policy
  * No more releases of Asterisk 1.0 will be made for any reason.
  *
- * \subsection ast10commits Commit Policy
  * No commits should be made to the Asterisk 1.0 branch.
  * 
  * <hr/>
  *
  * \section ast12policy Asterisk 1.2
  *
- * \subsection ast12releases Release Policy
- *
- * There will be no more scheduled releases of Asterisk 1.2.  Releases will be
- * made as needed to address security issues or regressions introduced by previous
- * security fixes.
- *
- * \subsection ast12commits Commit Policy
- *
+ * \subsection ast12releases Release and Commit Policy
+ *
+ * There will be no more scheduled releases of Asterisk 1.2.
+ * 
  * Commits to the Asterisk 1.2 branch should only address security issues or
  * regressions introduced by previous security fixes.  For a security issue, the
  * commit should be accompanied by an 
@@ -211,6 +206,72 @@
  * security advisory that is related to the change that introduced the bug should get
  * updated to indicate that there is an updated version of the fix.  A release should
  * be made immediately for these regression fixes, as well.
+ *
+ * <hr/>
+ *
+ * \section ast14policy Asterisk 1.4
+ *
+ * \subsection ast14releases Release and Commit Policy
+ *
+ * Asterisk 1.4 is receiving regular bug fix release updates.  An attempt is made to
+ * make releases of every four to six weeks.  Since this release series is receiving
+ * changes for all types of bugs, the number of changes in a single release can be
+ * significant.  1.4.X releases go through a release candidate testing cycle to help
+ * catch any regressions that may have been introduced.
+ *
+ * Commits to Asterisk 1.4 must be to address bugs only.  No new features should be
+ * introduced into Asterisk 1.4 to reduce the number of changes to this established
+ * release series.  The only exceptions to this rule are for cases where something
+ * that may be considered a feature is needed to address a bug or security issue.
+ *
+ * <hr/>
+ *
+ * \section ast16policy Asterisk 1.6
+ *
+ * \subsection ast16releases Release and Commit Policy
+ *
+ * Asterisk 1.6 is managed in a different way than previous Asterisk release series.
+ * From a high level, it was inspired by the release model used for Linux 2.6.
+ * The intended time frame for 1.6.X releases is every 2 or 3 months.  Each 1.6.X
+ * release gets its own branch.  The 1.6.X branches are branches off of trunk.
+ * Once the branch is created, it only receives bug fixes.  Each 1.6.X release goes
+ * through a beta and release candidate testing cycle.
+ *
+ * After a 1.6.X release is published, it will be maintained until 1.6.[X + 3] is
+ * released.  While a 1.6.X release branch is still maintained, it will receive only
+ * bug fixes.  Periodic maintenance releases will be made and labeled as 1.6.X.Y.
+ * 1.6.X.Y releases should go through a release candidate test cycle before being
+ * published.
+ *
+ * For now, all previous 1.6 release will be maintained for security issues.  Once
+ * we have more 1.6 releases to deal with, this part of the policy will likely change.
+ * 
+ * For some history on the motivations for Asterisk 1.6 release management, see the
+ * first two sections of this
+ * <a href="http://lists.digium.com/pipermail/asterisk-dev/2007-October/030083.html">mailing list post</a>.
+ *
+ * <hr/>
+ *
+ * \section asttrunk Asterisk Trunk
+ *
+ * \subsection asttrunkpolicy Release and Commit Policy
+ *
+ * No releases are ever made directly from Asterisk trunk.
+ *
+ * Asterisk trunk is used as the main development area for upcoming Asterisk 1.6 
+ * releases.  Commits to Asterisk trunk are not limited.  They can be bug fixes,
+ * new features, and architectural improvements.  However, for larger sets
+ * of changes, developers should work with the Asterisk project leaders to
+ * schedule them for inclusion.  Care is taken not to include too many invasive
+ * sets of changes for each new Asterisk 1.6 release.
+ *
+ * No changes should go into Asterisk trunk that are not ready to go into a
+ * release.  While the upcoming release will go through a beta and release
+ * candidate test cycle, code should not be in trunk until the code has been
+ * tested and reviewed such that there is reasonable belief that the code
+ * is ready to go.
+ *
+ * <hr/>
  */
 
 /*!