s/for/from/ in docs

[gitmo/Moose.git] / lib / Moose / Manual / Contributing.pod

diff --git a/lib/Moose/Manual/Contributing.pod b/lib/Moose/Manual/Contributing.pod
index c161ae4..d7f62c9 100644 (file)
--- a/lib/Moose/Manual/Contributing.pod
+++ b/lib/Moose/Manual/Contributing.pod
@@ -84,10 +84,13 @@ everyone involved. The branches below are ordered by level of stability.
 =item stable/*
 
 The branch from which releases are cut. When making a new major release, the
-release manager makes a new C<stable/$version> branch at the current position
-of C<master>. For minor releases, patches will be committed to C<master>, and
-backported (cherry-picked) to the appropriate stable branch as needed. The
-C<stable> branch is only updated by someone from the Cabal during a release.
+release manager makes a new C<stable/X.YY> branch at the current position of
+C<master>. The version used in the stable branch should not include the last
+two digits of the version number.
+
+For minor releases, patches will be committed to C<master>, and
+backported (cherry-picked) to the appropriate stable branch as needed. A
+stable branch is only updated by someone from the Cabal during a release.
 
 =item master
 
@@ -121,10 +124,10 @@ moved here, to keep the main areas clean.
 
 =back
 
-Larger, more long term branches can also be created in the root namespace (i.e.
-at the same level as master and stable). This is more appropriate if multiple
+Larger, longer term branches can also be created in the root namespace (i.e.
+at the same level as master and stable). This may be appropriate if multiple
 people are intending to work on the branch. These branches should not be
-rebased.
+rebased without checking with other developers first.
 
 =head1 STANDARD WORKFLOW
 
@@ -216,8 +219,9 @@ branch's approval.
 
 =item Backwards incompatible changes.
 
-Anything that breaks backwards compatibility must be discussed by the cabal
-and agreed to by a majority of the members.
+Anything that breaks backwards compatibility must be discussed by the
+cabal. Backwards incompatible changes should not be merged to master if there
+are strong objections from any cabal members.
 
 We have a policy for what we see as sane L</BACKWARDS COMPATIBILITY> for
 Moose. If your changes break back-compat, you must be ready to discuss and
@@ -231,23 +235,23 @@ defend your change.
     git checkout master
 
     # minor releases
-    git checkout stable
+    git checkout stable/X.YY
 
     # edit for final version bumping, changelogging, etc
     # prepare release (test suite etc)
     perl-reversion -bump
     make manifest
     git commit
-    git branch stable/2.XXYY # only for non-trial major releases
+    git branch stable/X.YY # only for non-trial major releases
     shipit # does not ship the tarball, but does everything else
 
     # non-trial releases
-    cpan-upload ~/shipit-dist/Moose-2.XXYY.tar.gz
+    cpan-upload ~/shipit-dist/Moose-X.YYZZ.tar.gz
 
     # trial releases
     cd ~/shipit-dist
-    mv Moose-2.XXYY.tar.gz Moose-2.XXYY-TRIAL.tar.gz
-    cpan-upload Moose-2.XXYY-TRIAL.tar.gz
+    mv Moose-X.YYZZ.tar.gz Moose-X.YYZZ-TRIAL.tar.gz
+    cpan-upload Moose-X.YYZZ-TRIAL.tar.gz
 
 =head2 Release How-To
 
@@ -290,12 +294,12 @@ The stable branch exists for easily making bug fix releases.
     git commit
 
 Then a cabal member merges into C<master>, and backports the change into
-C<stable>:
+C<stable/X.YY>:
 
     git checkout master
     git merge topic/my-emergency-fix
     git push
-    git checkout stable
+    git checkout stable/X.YY
     git cherry-pick -x master
     git push
     # release
@@ -329,8 +333,8 @@ C<my-project> is a valid ref).
 
 Merged branches should be deleted.
 
-Failed branches may be kept, but should be to C<attic/> to differentiate them
-from in-progress topic branches.
+Failed branches may be kept, but should be moved to C<attic/> to differentiate
+them from in-progress topic branches.
 
 Branches that have not been worked on for a long time will be moved to
 C<abandoned/> periodically, but feel free to move the branch back to C<topic/>
@@ -352,6 +356,16 @@ We also greatly appreciate documentation to go with your changes, and an entry
 in the Changes file. Make sure to give yourself credit! Major changes or new
 user-facing features should also be documented in L<Moose::Manual::Delta>.
 
+=head1 DOCS, DOCS, DOCS
+
+Any user-facing changes must be accompanied by documentation. If you're not
+comfortable writing docs yourself, you might be able to convince another Moose
+dev to help you.
+
+Our goal is to make sure that all features are documented. Undocumented
+features are not considered part of the API when it comes to determining
+whether a change is backwards compatible.
+
 =head1 BACKWARDS COMPATIBILITY
 
 Change is inevitable, and Moose is not immune to this. We do our best
@@ -380,7 +394,7 @@ Jesse Luehrs E<lt>doy at tozt dot netE<gt>
 
 =head1 COPYRIGHT AND LICENSE
 
-Copyright 2009 by Infinity Interactive, Inc.
+Copyright 2009-2010 by Infinity Interactive, Inc.
 
 L<http://www.iinteractive.com>