(One intermediate revision by the same user not shown) | |||
Line 13: | Line 13: | ||
All these modules are branched, so the <code>devel</code> branch holds the newest release notes. Branching might seem unnecessary at first blush, but it is possible for the [[DocsProject| 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. | All these modules are branched, so the <code>devel</code> branch holds the newest release notes. Branching might seem unnecessary at first blush, but it is possible for the [[DocsProject| 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 <code>rpm-info.xml</code> file for each module MUST have the same version number as the overall release-notes module's <code>rpm-info.xml</code> AND <code>fedora-release-notes.spec</code> file. | {{important}} When building the release notes tarball, the <code>rpm-info.xml</code> file for each module MUST have the same version number as the overall release-notes module's <code>rpm-info.xml</code> AND <code>fedora-release-notes.spec</code> file. | ||
Update all Fedora release numbers in each module's <code>rpm-info.xml</code> file, and all Fedora release numbers in any content <code>.xml</code>, <code>.omf.in</code>, or <code>.desktop.in</code> files. Remember to check the attributes in XML elements. | Update all Fedora release numbers in each module's <code>rpm-info.xml</code> file, and all Fedora release numbers in any content <code>.xml</code>, <code>.omf.in</code>, or <code>.desktop.in</code> files. Remember to check the attributes in XML elements. | ||
Line 21: | Line 21: | ||
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. | 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. | ||
{{ /code | {{important}} Retain the changelog in the <code>fedora-release-notes.spec</code> file. This is useful and expected to grow from release to release. | ||
== Translations == | == Translations == |
Latest revision as of 00:23, 11 July 2008
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 :
about-fedora
homepage
readme
readme-burning-isos
readme-live-image
release-notes
Versioning
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.
When building the release notes tarball, the rpm-info.xml
file for each module MUST have the same version number as the overall release-notes module's rpm-info.xml
AND fedora-release-notes.spec
file.
Update all Fedora release numbers in each module's rpm-info.xml
file, and all Fedora release numbers in any content .xml
, .omf.in
, or .desktop.in
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 fedora-release-notes.spec
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 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.
Building
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:
make release-srpm
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 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
rpm-info.xml
file in that module. You probably forgot to update that module to match the Version tag in thefedora-release-notes.spec
file.