Documentation Release Process

This page is intended to gather the steps for a release of the GnuCash documentation. It was animated by Bug 652350 - Formalize the Documentation release process and is partial related to the code Release Process.

ATTENTION This is a draft version, cloned from the program's release process and gradually being tailored for the documentation release process

Backport Policy

Check the Subversion#Current_Backport_Policy.

Checkout release branch

• Determine which branch to do the release from:

• If you are about to release a development snapshot, choose trunk
• If you want to release a new stable version and the stable series is already on its own branch, then choose that stable branch, eg. 2.4
• If you want to release a new stable version but the stable series is still on trunk, then choose trunk

• Check out the proper gnucash-docs Subversion branch.

Checks and Updates

• Check if Authors, Maintainers and Translators from main documents are in sync with
  • the related OMF files (has someone expirience with existing tools for this task?) and
  • AUTHORS
• Check if gnucash/DOCUMENTERS both trunk and stable is in sync with gnucash-docs/AUTHORS.
• Update NEWS (can we adapt some mechanic from gnucashs Changelog updates?)
• Update the version number of the [AM_INIT_AUTOMAKE] macro in configure.in
• Commit this change

Subversion

• Verify that the chosen branch can build a distribution tarball, compile, and test it fine:

./autogen.sh
./configure
make distcheck

Fix any errors this step may turn up, commit and check again.

• Copy the subversion trunk to the tags/<version-number>. For example:

svn cp svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk svn+ssh://svn.gnucash.org/repo/gnucash-docs/tags/2.4.2 -m "Tag 2.4.2"

Remember to use the proper source branch here!

Source tarballs

• Checkout the release tag from subversion. Do a clean checkout here to avoid packaging unreleased changes ! For example:

svn co svn+ssh://svn.gnucash.org/repo/gnucash-docs/tags/2.4.2 v2.4.2

• Inside v2.4.2, run

./autogen.sh
mkdir build
cd build
../configure
make distcheck

Note that the build is done in a subdirectory here. This is not strictly necessary, but it will simplify some of the future steps in the documentation release process.

The above commands should generate a gzip compressed tarball in the build directory. (Using "make distcheck" instead of only "make dist" does not only create the tarball, but also runs a complete compilation run on the created tarball, so that missing files are discovered immediately.)

Other documentation formats

Next to source tarballs, GnuCash also offers the documentation in several other formats for on-line or off-line reading. Currently these formats are html, pdf, epub and mobi.

• In the same build directory we created in the previous step, run

../configure --with-mobi
make html pdf epub mobi

This should generate the various alternative formats in subdirectories per document (guide or help) and per language (like C, de_DE, it_IT and so on).

FIXME The standard setup will refuse to build a Japanese pdf due to missing fonts. To build the Japanese pdf, additional fonts have to be installed and fop-ttfreader must be present. I didn't manage to set this up properly on a Fedora 16 system.

Sourceforge file uploads

The tarball generated above should be uploaded to Source Forge.

• Log in on the [Source Forge GnuCash website]
• Go to the Project Admin -> File Manager section
• Create a new directory for the release under gnucash-docs
• Upload the file created above to this directory.

GnuCash Website

Uploading the new documentation versions

The additional documentation formats have to be uploaded to the gnucash website. The website is also managed in subversion, so to get the documentation in there, the current website sources have to be checked out:

• Move one level up from the v2.4.2 directory created above

svn co svn+ssh://svn.gnucash.org/repo/htdocs/trunk htdocs

You should now have the v2.4.2 and htdocs directories next to each other. Inside the htdocs directory you will find a subdirectory docs and in there a subdirectory per major release (1.8, 2.0, 2.2,...). If no directory exists yet for the major version of the documentation you about to release, then first create this directory and check it in, for example:

cd htdocs/docs
mkdir v2.4
svn ci -m "Create v2.4 documentation directory"
cd ../..

Note that each version directory starts with a lowercase "v" (from "version")

Next, we'll copy all of the alternative documentation formats into the version directory. The most efficient way is by using rsync. These commands accomplish this:

base=$PWD
(cd v2.4.2/build/guide; for i in C de_DE it_IT ja_JP; do rsync -av --delete $i/gnucash-guide{,.pdf,.epub,.mobi} $base/htdocs/docs/v2.4/$i/;done)
(cd v2.4.2/help; for i in C de_DE it_IT; do rsync -av --delete $i/gnucash-help{,.pdf,.epub,.mobi} $base/htdocs/docs/v2.4/$i/;done)

Note that the commands should be run from the parent directory of v2.4.2 and htdocs, and the parentheses are important.

If that worked well, you can no go into the htdocs directory and use svn add to add new files and svn rm to remove deleted files from the repository (if any):

cd htdocs
svn stat
# This will show a list of new/changed/deleted files.
svn add [new files]...
svn rm [deleted files]...
svn ci -m "Add documentation version 2.4.2 to the GnuCash website"

Adding the announcement text

• Go to your GnuCash svn source directory
• cd util/svnlog2ul/
• Run the 'svnlog2ul.sh' utility to get the commit messages relevant to this release. For example:

./svnlog2ul.sh 2.3.9 2.3.10 > 2.3.10-commits.html

Use the output together with a previous news file to generate a newsmessage for this release. The easiest way is probably to copy the old newsfile into a new one, replace all occurrences of the old release number with the new release number and then insert the list of commits.

• Check out subversion htdocs

svn co svn+ssh://svn.gnucash.org/repo/htdocs/trunk/ gnucash-htdocs

• Go to the news files

cd gnucash-htdocs/news

• Copy the last release newsfile. The filename format is usually YYMMDD-<releasenumber>.news. For example:

svn cp 100217-2.3.10.news 100316-2.3.11.news

• Replace the old release numbers in this file. Note that release announcements usually contain two release numbers: the current release and the previous release. Both of them should obviously be replaced. The order to execute the following commands is important ! For example:

sed -i -e 's/2.3.10/2.3.11/g' 100316-2.3.11.news
sed -i -e 's/2.3.9/2.3.10/g' 100316-2.3.11.news

• Now open the file in your favourite editor and replace the changes with the commit messages you had just created. You will have to manually bring some order in the commits (for example, put the commits that fix bugs together in one group, other user visible changes in another group and internal changes in still another one)

Updating the release number for the download pointers

Next, the release number should be added to the website configuration script. This ensures all download links are appropriately updated.

• Edit the file gnucash-htdocs/externals/global_params.php. The first few lines in this script set various release numbers: latest_stable, latest_unstable and variants thereof on Windows and MacOS X. Adapt these parameters as needed.

Finally, all these changes to the website should be committed.

svn ci -m "Update to release x.y.z"

The commit will take care of updating the live website.

Mailing list announcement

Send the same announcement to the following lists:

• gnucash-devel@gnucash.org
• gnucash-user@gnucash.org
• gnucash-announce@gnucash.org

To do so, you have to be subscribed to the mailing lists. Then I found it easiest to copy the release announcement from my web browser into a new mail message (Kmail). In kmail this converts the html in a reasonably clean plain-text message. Some further minor cleanup may be necessary.

Bugzilla

Add the new version number.