Author: cmpilato
Date: Mon Jul 11 20:50:25 2011
New Revision: 1145343
URL: http://svn.apache.org/viewvc?rev=1145343&view=rev
Log:
* site/publish/docs/community-guide/issues.part.html
Be a bit more explicit when discussing our major release milestones.
Modified:
subversion/site/publish/docs/community-guide/issues.part.html
Modified: subversion/site/publish/docs/community-guide/issues.part.html
URL:
http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/issues.part.html?rev=1145343&r1=1145342&r2=1145343&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/issues.part.html (original)
+++ subversion/site/publish/docs/community-guide/issues.part.html Mon Jul 11
20:50:25 2011
@@ -224,10 +224,10 @@ understand those distinctions.</p>
<tt>NEW</tt>, <tt>STARTED</tt> or <tt>REOPENED</tt>), the milestone
indicates the Subversion release for which the developers are
targeting the resolution of that issue. In the general case, we use
-milestones of the form <tt><em>VERSION</em>-consider</tt> to indicate
+milestones of the form <tt><em>MINORVERSION</em>-consider</tt> to indicate
that the resolution of an issue is being considered as something we'd
-like to release in <em>VERSION</em>. For example, a feature we think
-we can and should add to Subversion 1.9 will get
+like to release in <em>MINORVERSION</em>.0. For example, a feature we think
+we can and should add to Subversion 1.9.0 will get
a <tt>1.9-consider</tt> milestone. For obvious reasons, the accuracy
of these release targets gets increasingly worse the farther into the
future you look and, as such, users are encouraged to <em>not</em>
@@ -240,12 +240,12 @@ for the release (also known as "release
"nice-to-haves", and which ones should be deferred to a future release
altogether. Issue milestones are the mechanism used to carry the
results of those decisions. An issue that is deemed to be a release
-blocker will be moved from the <tt><em>VERSION</em>-consider</tt>
-milestone to the <tt><em>VERSION</em></tt> milestone;
+blocker will be moved from the <tt><em>MINORVERSION</em>-consider</tt>
+milestone to the <tt><em>MINORVERSION</em>.0</tt> milestone;
"nice-to-haves" will be left with
-the <tt><em>VERSION</em>-consider</tt> milestone; and issues deferred
+the <tt><em>MINORVERSION</em>-consider</tt> milestone; and issues deferred
from the release will be re-milestoned either
-with <tt><em>ANOTHERVERSION</em>-consider</tt>
+with <tt><em>ANOTHERMINORVERSION</em>-consider</tt>
or <tt>unscheduled</tt>, depending on whether we have a clear guess as
to when the issue will be addressed.</p>
@@ -260,7 +260,7 @@ aren't going to get around to implementi
release series, we'll re-milestone the issue to something else
(<tt>1.10-consider</tt>, perhaps).</p>
-<p>The accuracy of the <tt><em>VERSION</em></tt> milestone is very
+<p>The accuracy of the <tt><em>MINORVERSION</em>.0</tt> milestone is very
important, as developers tend to use those issues to focus their
efforts in the final days of a major release cycle.</p>
@@ -310,8 +310,8 @@ previous release stream needs to have it
that previous release's version number. Finally, a resolved issue
that gets <tt>REOPENED</tt> needs to have its milestone reevaluated in
terms of whether the issue is a release blocker
-(<tt><em>VERSION</em></tt>) or not
-(<tt><em>VERSION</em>-consider</tt>). In such situations, it can be
+(<tt><em>MINORVERSION</em>.0</tt>) or not
+(<tt><em>MINORVERSION</em>-consider</tt>). In such situations, it can be
helpful to consult the issue's change history to see what milestone
was used before the issue was resolved as fixed.</p>
