Immanetize (talk | contribs) |
Immanetize (talk | contribs) |
||
Line 9: | Line 9: | ||
==ensure source builds== | ==ensure source builds== | ||
<code> publican build -l en-US -f html | <code> publican build -l en-US -f html</code> | ||
You're doing this often anyway, right? | You're doing this often anyway, right? | ||
Revision as of 07:23, 8 March 2013
create release branch
git branch f19
- Pull en_US source from master
At first, the release branch should mirror the master branch. Changes are pulled over to the release branch for release milestones - alpha, beta, and GA release. Active work is done in the master branch. We can check out a file from the master branch to apply.
git checkout f19
git checkout master -- file.xml
ensure source builds
publican build -l en-US -f html
You're doing this often anyway, right?
Push POTs, Pull POs
Early in the milestone cycle, push the source to transifex.
publican update_pot
tx push -s
After translation has been performed, check the transifex dashboard and pull *only* completed translations.
tx pull fr
tx pull nl
test to ensure translations build
Of course, all languages must build. Test that:
publican build -l fr-FR -f html
publican build -l nl-NL -f html
Fix any issue that you can, and push POs back to transifex:
tx push -t
Remove any docs that do not build.
Prep the branch
Add the source and POs to the git repo.
git add {en-US,fr-FR,nl-NL}/*
Pull over the barebones desktop file and language index
git checkout master -- build/{document.desktop,index.html}
git commit -a -m 'adding langs'
review the regex
The sample spec file contains regular expressions to extract certain information. These regular expressions should be fine once adapted to a specific document. Initially, they will probably have to be adjusted.
tag the release branch
The end result will be an RPM with a filename of the form %{name}-%{release}-%{version}.rpm and we want our git tag to match. For example, if building a package for f19 for the third time, the tag could be '19-3.fc19'.
git tag -a 19-3.fc19 -m 'updated translations for document'
Check the tag!
The spec file should be consulted to get the correct tag information. If in doubt, bump the version in the spec file and run rpmlint
on it to see how the variables are substituted.
Alpha and Beta Versions
Alpha and beta releases should follow the naming guidelines for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
wget the source and perform a mock build
Test with rpmlint again. Sources can take a a while to become available for download, so rpmlint may complain unjustly. wget the tar.bz2 file described in rpmlint's output to verify the release is tagged correctly and the file is available.
Perform a local build, and a mock build.
rpmlint resulting package
push the tarball to scm
scratch build in koji
branch build in koji
push to testing
announce availability for testing
push to stable