From: Trevor Daniels <t.daniels@treda.co.uk>
Date: Thu, 16 Jan 2014 13:16:04 +0000 (+0000)
Subject: Doc: Issue 3807: Maintaining \version in documentation files
X-Git-Tag: release/2.19.1-1~6
X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=643e6b2322f7091cde05b7add4903634c661cf0e;p=lilypond.git

Doc: Issue 3807: Maintaining \version in documentation files

  Add instructions on maintaining the \version string in doc files
---

diff --git a/Documentation/contributor/doc-work.itexi b/Documentation/contributor/doc-work.itexi
index 680522cbc9..c6d8560c0b 100644
--- a/Documentation/contributor/doc-work.itexi
+++ b/Documentation/contributor/doc-work.itexi
@@ -14,6 +14,7 @@ Version Control System (VCS) called git, previously discussed in
 
 @menu
 * Introduction to documentation work::
+* version in documentation files::
 * Documentation suggestions::
 * Texinfo introduction and usage policy::
 * Documentation policy::
@@ -66,6 +67,39 @@ Before undertaking any large documentation work, contributors are
 encouraged to contact the @ref{Meisters, Documentation Meister}.
 
 
+@node version in documentation files
+@section @code{\version} in documentation files
+
+Every documentation file which includes LilyPond code should begin
+with a @code{\version} statement referencing a version of LilyPond
+consistent with the syntax of the contained code.
+
+The @code{\version} statement should be commented out to avoid
+creating problems when building releases with GUB, like this:
+
+@example
+%c \version "2.19.1"
+@end example
+
+So, if you are adding LilyPond code which is not consistent with the
+current version header, you should
+
+@enumerate
+
+@item
+run convert-ly on the file using the latest version of LilyPond
+(which should, if everybody has done proper maintenance, not change
+anything);
+
+@item
+add the new code;
+
+@item
+modify the version number to match the new code.
+
+@end enumerate
+
+
 @node Documentation suggestions
 @section Documentation suggestions