| [ << Programming work ] | [Top][Contents][Index][ ? ] | [ Release work >> ] | ||
| [ < Automatically update documentation ] | [ Up : Adding or modifying features ] | [ Edit changes.tely > ] | ||
10.9.5 Manually update documentation
Where the convert-ly rule is not able to automatically update the inline LilyPond code in the documentation (i.e. if a NOT_SMART rule is used), the documentation must be manually updated. The inline snippets that require changing must be changed in the English version of the docs and all translated versions. If the inline code is not changed in the translated documentation, the old snippets will show up in the English version of the documentation.
Where the convert-ly rule is not able to automatically update snippets in Documentation/snippets/, those snippets must be manually updated. Those snippets should be copied to Documentation/snippets/new. The comments at the top of the snippet describing its automatic generation should be removed. All translated texidoc strings should be removed. The comment “% begin verbatim” should be removed. The syntax of the snippet should then be manually edited.
Where snippets in Documentation/snippets are made obsolete, the snippet should be copied to Documentation/snippets/new. The comments and texidoc strings should be removed as described above. Then the body of the snippet should be changed to:
\markup {
This snippet is deprecated as of version X.Y.Z and
will be removed from the documentation.
}
where X.Y.Z is the version number for which the convert-ly rule was written.
Update the snippet files by running:
scripts/auxiliar/makelsr.py
Where the convert-ly rule is not able to automatically update regression tests, the regression tests in input/regression should be manually edited.
Although it is not required, it is helpful if the developer can write relevant material for inclusion in the Notation Reference. If the developer does not feel qualified to write the documentation, a documentation editor will be able to write it from the regression tests. In this case the developer should raise a new issue with the Type=Documentation tag containing a reference to the original issue number and/or the committish of the pushed patch so that the need for new documention is not overlooked.
Any text that is added to or removed from the documentation should be changed only in the English version.
| [ << Programming work ] | [Top][Contents][Index][ ? ] | [ Release work >> ] | ||
| [ < Automatically update documentation ] | [ Up : Adding or modifying features ] | [ Edit changes.tely > ] | ||