Merge branch 'master' into lilypond/translation

[lilypond.git] / Documentation / contributor / programming-work.itexi

diff --git a/Documentation/contributor/programming-work.itexi b/Documentation/contributor/programming-work.itexi
index ef917b5afcd41ec39e22f77f8ef51ae916f535ca..672533ecb89f20f56beddb91382f013ba398d055 100644 (file)
--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -1177,6 +1177,19 @@ of the file.  In some cases, this will not be possible, so the
 rule will simply point out to the user that the feature needs
 manual correction.
 
 rule will simply point out to the user that the feature needs
 manual correction.
 

+@subsubheading Updating version numbers
+
+If a development release occurs between you writing your patch and
+having it approved+pushed, you will need to update the version
+numbers in your tree.  This can be done with:
+
+@example
+scripts/auxiliar/update-patch-version old.version.number new.version.number
+@end example
+
+It will change all files in git, so use with caution and examine
+the resulting diff.
+

 
 @node Automatically update auxiliary information
 @subsection Automatically update auxiliary information
 
 @node Automatically update auxiliary information
 @subsection Automatically update auxiliary information


@@ -1373,79 +1386,7 @@ layout, MIDI, performance or error reporting.
 @node Post patch for comments
 @subsection Post patch for comments
 
 @node Post patch for comments
 @subsection Post patch for comments
 

-For any change other than a minor change, a patch set should be
-posted on @uref{http://codereview.appspot.com/, Rietveld} for comment.
-This requires the use of an external package, git-cl, and an email
-account on Google.
-
-git-cl is installed by:
-
-@example
-git clone git://neugierig.org/git-cl.git
-@end example
-
-Then, add the git-cl directory to your PATH, or create a
-symbolic link to the git-cl and upload.py in one of your
-PATH directories (like usr/bin).  git-cl is then
-configured by entering the command
-
-@example
-git cl config
-@end example
-
-@noindent
-in the LilyPond git directory and answering the questions that
-are asked.  If you do not understand the question answer with just
-a newline (CR).
-
-The patch set is posted to Rietveld as follows.  Ensure your changes
-are committed in a separate branch, which should differ from the
-reference branch to be used by just the changes to be uploaded.
-If the reference branch is to be origin/master, ensure this is
-up-to-date.  If necessary, use git rebase to rebase the branch
-containing the changes to the head of origin/master.  Finally,
-check out branch with the changes and enter the command:
-
-@example
-git cl upload <reference SHA1 ID>
-@end example
-
-@noindent
-where <reference SHA1 ID> is the SHA1 ID of the commit to be used
-as a reference source for the patch.  Generally, this will be the
-SHA1 ID of origin/master, and in that case the command
-
-@example
-git cl upload origin/master
-@end example
-
-@noindent
-can be used.
-
-After prompting for your Google email address and password, the
-patch set will be posted to Rietveld.
-
-You should then announce the patch by sending
-an email to lilypond-devel, with a subject line
-starting with PATCH:, asking for comments on the patch.
-
-As revisions are made in response to comments, successive patch sets
-for the same issue can be uploaded by reissuing the git-cl command
-with the modified branch checked out.
-
-Sometimes in response to comments on revisions, the best way to
-work may require creation of a new branch in git.  In order to
-associate the new branch with an existing Rietveld issue,
-the following command can be used:
-
-@example
-git cl issue issue-number
-@end example
-
-@noindent
-where @code{issue-number} is the number of the existing Rietveld
-issue.
-
+See @ref{Uploading a patch for review}.

 
 
 @node Push patch
 
 
 @node Push patch