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 :
All these modules are branched, so the
devel 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.
Update all Fedora release numbers in each module's
rpm-info.xml file, and all Fedora release numbers in any content
.desktop.in files. Remember to check the attributes in XML elements.
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.
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.
fedora-release-notes.spec file properly. This normally means at least bumping the Version and Release tag, and making an entry in the
%changelog section. Follow previous examples for guidance.
Make sure all work in all modules is correct, and committed to CVS, before you begin. In the
release-notes directory (in the same directory with the
Makefile), use the following command:
This command produces a source RPM (SRPM) package. You can then carry the
.src.rpm file to the Fedora Package CVS, in the
fedora-release-notes/devel module, and run
cvs-import.sh <SRPM_FILE> to update everything automatically. Then you should check your work with
make mockbuild, before finally doing
make tag build 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 email@example.com or a representative on IRC to notify them about the work you complete.
- If you get an error message that informs you about a missing directory with an older version number, check the
rpm-info.xmlfile in that module. You probably forgot to update that module to match the Version tag in the