apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From traw...@apache.org
Subject svn commit: r1311706 - /apr/site/trunk/xdocs/guidelines.xml
Date Tue, 10 Apr 2012 13:14:26 GMT
Author: trawick
Date: Tue Apr 10 13:14:26 2012
New Revision: 1311706

URL: http://svn.apache.org/viewvc?rev=1311706&view=rev
Log:
document procedures related to CHANGES and branch maintenance

Modified:
    apr/site/trunk/xdocs/guidelines.xml

Modified: apr/site/trunk/xdocs/guidelines.xml
URL: http://svn.apache.org/viewvc/apr/site/trunk/xdocs/guidelines.xml?rev=1311706&r1=1311705&r2=1311706&view=diff
==============================================================================
--- apr/site/trunk/xdocs/guidelines.xml (original)
+++ apr/site/trunk/xdocs/guidelines.xml Tue Apr 10 13:14:26 2012
@@ -54,6 +54,53 @@ Then Commit" (RTC) process.</p>
 </section>
 
 <section>
+<title>CHANGES entries</title>
+
+<p>The goals for CHANGES entries are to provide this documentation
+for user-visible changes and to limit this documentation to releases
+which introduced the change.  Fixes to features which have not yet been
+released don't warrant an entry as they are part of the initial release
+of the feature.  CHANGES for one branch shouldn't duplicate entries for
+earlier branches except when releases introducing the fix are created
+from both branches.</p>
+
+<p>Modifications expected to remain only in trunk, at least for some
+time, should be accompanied by a CHANGES entry in trunk (if a CHANGES
+entry is appropriate at all).</p>
+
+</section>
+
+<section>
+<title>Branch maintenance</title>
+
+<p>Many changes which are committed to trunk are also delivered to other
+branches.  The procedure used is outlined below.</p>
+
+<p>
+Commit to trunk, 1.9.x, 1.8.x, etc. down to the actively maintained
+stable branch. In cases where the actively maintained stable branch
+has recently changed, such as when moving from 1.3.x to 1.4.x in order
+to release new features, it is up to the committer to decide whether to
+commit to the previous actively maintained stable branch.  (There is
+at least limited value in having the project decide what the patch for
+some branch is even if there are no clear plans to release it, as some
+users may need to continue using the previous branch for some time
+until they can vet the changes in the current branch.)</p>
+
+<p>Commit messages for the branches always explicitly reference the trunk
+revision.  In particular, note that Subversion mergeinfo is not a 
+sufficient record because it does not show up in commonly-used views of
+revision history.</p>
+
+<p>When a CHANGES entry is needed for the modifications committed to a
+branch, the CHANGES entry should be part of the commit, whether or not 
+it was part of the trunk revision being backported.  (A CHANGES entry is
+commonly omitted from the trunk commit if a backport will be performed
+almost immediately.)</p>
+
+</section>
+
+<section>
 <title>PMC Membership</title>
 
 <p>PMC membership is attained through a "consensus approval" process



Mime
View raw message