User:Pfrields/Drafts/ReleaseNotesHowto

= Fedora Release Notes Production HOWTO =

The fedora-release-notes package in Fedora is built from a group of six (6) different modules in Fedora Docs CVS :

Versioning
All these modules are branched, so the  branch holds the newest release notes. Branching might seem unnecessary at first blush, but it is possible for the Docs Project  to produce a midstream update for any currently maintained release. The major version number must ALWAYS match the Fedora release for which the notes are intended. For Fedora 9, the version numbers 9, 9.0, 9.0.0, 9.0.1, and so on, are all acceptable. Historically the first release is X.0.0, and any simple content updates are represented as X.0.1, X.0.2, and so on.

When building the release notes tarball, the  file for each module MUST have the same version number as the overall release-notes module's   AND   file.

Update all Fedora release numbers in each module's  file, and all Fedora release numbers in any content ,  , or   files. Remember to check the attributes in XML elements.

Revision History
There is no sense in maintaining revision history for these modules, since they follow the release so closely. remove any previou revision history, except possibly from the testing phases leading up to the final release. For instance, keeping revision history from a 9.92 release notes release as well as the entry for the final version (10.0.0) is acceptable.

Retain the changelog in the  file. This is useful and expected to grow from release to release.

Translations
Because of the way release timing and translation (PO and POT file) production schedules interact, you may end up needing to change some version or release numbering after the translation deadline. Use a PO-aware editor such as Emacs (or Vim) to edit these numbers if they appear in translatable strings, being careful not to disturb the rest of the translation! Remember to remove the "fuzzy attribute" if this is the only content change.

Spec File
Update the  file properly. This normally means at least bumping the Version and Release tag, and making an entry in the  section. Follow previous examples for guidance.

Building
Make sure all work in all modules is correct, and committed to CVS, before you begin. In the  directory (in the same directory with the  ), use the following command:

make release-srpm

This command produces a source RPM (SRPM) package. You can then carry the  file to the Fedora Package CVS, in the   module, and run   to update everything automatically. Then you should check your work with, before finally doing   to submit your work to the build system.

Fedora Release Engineering will check the results and tag them for inclusion in the distribution where necessary. It is a good idea to contact rel-eng@fedoraproject.org or a representative on IRC to notify them about the work you complete.

Troubleshooting

 * If you get an error message that informs you about a missing directory with an older version number, check the  file in that module.  You probably forgot to update that module to match the Version tag in the   file.