From Fedora Project Wiki

Revision as of 13:19, 16 October 2010 by Jjmcd (talk | contribs) (Created page with '{{header|docs}} Before the final release of Fedora, the Release Notes need to be prepared for release. This process should also be executed prior to beta, but at beta there ar...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

DocsProject Header docTeam1.png


Before the final release of Fedora, the Release Notes need to be prepared for release. This process should also be executed prior to beta, but at beta there are often no translations and the beats may not be in the best of shape.

Prepare the en-US

Review all of the beats to be certain new content has not been added. If necessary, add/edit the XML to reflect changes in the beats.

Proofread the en-US and make any important corrections. Be careful not to make unnecessary changes as these will break translations, and you should strive to minimize broken translations.

Adjust the version number in Revision_History.xml. For release notes, the version is of the form x.y, the x reflects the release of Fedora and y represents the change ordinal for the XML. For alpha and beta, x should be the Fedora release number minus 1, and y is 95 for Alpha and 98 for Beta. XML release notes are generally not produced for Alpha.

The RPM (and tar) version will be x.y.z where z represents the tar file ordinal. Typically the tar file will change as new translations are added, so new tars might be produced even in the absence of XML changes.

Remove the draft status in Release_Notes.xml.

Don't forget to push these changes back to git.

Make a clean working copy

To ensure that you have the latest translations and the RPM ultimately reflects the git contents it is best to start with a clean clone in a clean directory so there is no confusion as to what will be packaged.

 mkdir scratch
 mkdir scratch/temp
 cd scratch
 git clone ssh://git.fedorahosted.org/git/docs/release-notes.git
 cd release-notes
 cp en-US/* ../temp/

Note that, in a perfect world, you would not need to push anything back to git, so you could use the git:// form of the clone, but invariably there will be errors to correct and these should be pushed back, so the ssh:// form is preferred.

Build the non-en-US documents

Switch to the translation branch

git checkout --track -b f14 origin/f14

(Where the two f14's reflect the current release.)

Open the transifex page in a browser