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 the fedora-release-notes.spec file.

@@ Line 1: / Line 1: @@
 = Fedora Release Notes Production HOWTO =
-[[TableOfContents()]
 The fedora-release-notes package in Fedora is built from a group of six (6) different modules in [http://cvs.fedoraproject.org/viewcvs/?root=docs Fedora Docs CVS] :
@@ Line 14: / 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.
-{{ /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.
@@ Line 23: / 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.
-{{ /code/|  file.  This is useful and expected to grow from release to release.
+{{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 ==

Search

User:Pfrields/Drafts/ReleaseNotesHowto: Difference between revisions