Difference between revisions of "Documentation Release Process"

From GnuCash
Jump to: navigation, search
(Source tarballs: Adapt source tarballs step)
m (Checks and Updates: typo)
(76 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This page is intended to gather the steps for a release of the GnuCash documentation. It was animated by [https://bugzilla.gnome.org/show_bug.cgi?id=652350 Bug 652350 - Formalize the Documentation release process] and is partial related to the code [[Release Process]].
+
This page gathers the steps for a release of the GnuCash documentation. It was animated by [https://bugzilla.gnome.org/show_bug.cgi?id=652350 Bug 652350 - Formalize the Documentation release process].
  
'''ATTENTION This is a draft version, cloned from the program's release process and gradually being tailored for the documentation release process'''
+
== URLs ==
 +
{| border="1" cellpadding="5" cellspacing="0" bgcolor="white"
 +
| URL
 +
| Meaning
 +
|-
 +
| ssh://code.gnucash.org/gnucash-docs
 +
| source files of the docs
 +
|-
 +
| ssh://code.gnucash.org/gnucash-htdocs-docs
 +
| ready docs to be presented at ...
 +
|-
 +
| ssh://code.gnucash.org/gnucash-htdocs
 +
| source files of www.gnucash.org
 +
|-
 +
|}
 +
== Releases ==
 +
Beginning with 2.6.0, documentation releases should be done at the same time as GnuCash releases, with the Documentation release number corresponding to the GnuCash release. Do this even if there are no significant documentation changes in order to keep the numbers synchronized.
  
== Backport Policy ==
+
== Branching Policy ==
Check the [[Subversion#Current_Backport_Policy]].
+
As with development, we maintain two documentation branches, '''master''' and '''maint''' for whatever the current stable version is (at this writing it's '''2.6''').
 +
* Documentation updates describing features which are ''exclusively in code's master branch'' should be applied only on ''master''.
 +
* All others should be ''applied on maint'' and then ''merged in master''. 
  
== Subversion ==
+
Check [[Git#Branching and Merging]] to see if something changed.
* Check out gnucash-docs [[Subversion]] trunk.
+
 
* Verify that current trunk can build a distribution tarball, compile, and test it fine:
+
== Major Releases ==
 +
A major release is the first release to bring new development features to the users. This is shown by a jump in the version number (for example from 2.6.x to 2.8.0), and signifies the start of a new major development cycle.
 +
 
 +
=== git ===
 +
This means the branches in our repository have to be reshuffled. The release is done from a commit on the master branch. This commit should now become the HEAD commit for the maint branch because maintenance should now happen from there on. At the same time it may be necessary to keep up maintenance to the previous major series, so this should now get its own branch.
 +
 
 +
  git branch maint-X.Y maint # for example git branch maint-2.6 maint
 +
  git checkout maint
 +
  git merge --ff-only master
 +
 
 +
 
 +
;[https://github.com/Gnucash/gnucash-docs/blob/maint/docbook/gnc-docbookx.dtd#L35 docbook/gnc-docbook.dtd]: Update <!ENTITYs vers-unstable ... series-stable.
 +
 
 +
=== GnuCash Wiki ===
 +
This is now done by templates, see [[Release_Process#Update_Release_Version]].
 +
 
 +
=== Website ===
 +
Create a new directory for the documentation in the website repo:
 +
  mkdir v{{MainVersion}}
 +
  git add v{{MainVersion}}
 +
 
 +
== Checkout release branch ==
 +
* Determine which branch to do the release from:
 +
** If you want to release a new maintenance release on the ''current stable'' series (like 2.6.1, 2.6.2,...) then choose '''maint'''
 +
** If you want to release a new maintenance release on an ''older stable'' series (like 2.4.16 if 2.6.x is the current stable series) then choose '''maint-X.Y'''
 +
** If you are about to release a ''development snapshot'' (like 2.7.0, 2.7.1,...), choose '''master'''
 +
* Clone gnucash-docs if you don't already have one.
 +
  git clone ssh://code.gnucash.org/gnucash-docs
 +
* Check out the branch you want and make sure that it's up-to-date:
 +
  cd gnucash-docs
 +
  git checkout <branch>
 +
  git pull --rebase
 +
 
 +
If you are about to release from '''master''' you should verify that '''master''' is a ''superset'' of '''maint'''. You can do this by running the following command
 +
  git log master..maint
 +
This command should not list any commits. If it does, checkout '''master''' and merge '''maint''' into it.
 +
  git checkout master
 +
  git merge maint
 +
 
 +
;Note: The same check should be performed when releasing from '''maint''' and there is an older '''maint-X.Y''' branch on which commits still happen.
 +
 
 +
== Checks and Updates ==
 +
 
 +
;[https://github.com/Gnucash/gnucash-docs/blob/maint/docbook/gnc-docbookx.dtd#L33 docbook/gnc-docbookx.dtd]: Update <!ENTITYs manrevision and date.
 +
 
 +
* In each copy of gnucash-help.xml and gnucash-guide.xml, update the document history.
 +
 
 +
* Update the copyright - the year might change.
 +
* 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 on both development and stable branches is in sync with gnucash-docs/AUTHORS.
 +
* Update the version number of the <tt>[AC_INIT]</tt> macro in <tt>configure.ac</tt>
 +
* Update NEWS by running ../gnucash/util/git-release-notes.pl > release.news and copying over the changes, reformatting appropriately.
 +
* Update the ChangeLog:
 +
  git log --format="%ad %aN %n%n%x09* %s%d%n" --date=short <previous release tag>.. > ChangeLogNew
 +
  mv ChangeLog ChangeLogOld
 +
  cat ChangeLogNew ChangeLogOld > ChangeLog
 +
  rm ChangeLogNew
 +
  rm ChangeLogOld
 +
* Commit this change as "Release X.X.X"
 +
 
 +
== Git ==
 +
* Verify that the chosen branch can build a distribution tarball, compile, and test it satisfactorily:
 +
./autogen.sh
 +
./configure
 
  make distcheck
 
  make distcheck
:In this step, some files might have been changed such as POTFILES.in, which can then be committed before actually incrementing the version number. However, some of the test data files might also have been changed due to "make check", but those changes should not be committed.
+
:Fix any errors this step may turn up, commit and check again.
* Update the version number of the <tt>[AC_INIT]</tt> macro in <tt>configure.ac</tt>
+
* Tag the release and push:
* Commit this change in subversion
+
  git tag -am "Release 3.4" 3.4
* Copy the subversion trunk to the tags/<version-number>. For example:
+
  git push --tags origin <branch>
svn cp svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk svn+ssh://svn.gnucash.org/repo/gnucash-docs/tags/2.4.1 -m "Tag 2.4.1"
+
'''N.B.''' If after pushing the tag you discover a problem, fix the problem and tag the new commit with a lower-case letter subscript, e.g.  
 +
  git -tag -am "Re-tag of release 3.4" 3.4a
  
 
== Source tarballs ==
 
== Source tarballs ==
* Checkout the release tag from subversion. '''Do a clean checkout here to avoid packaging unreleased changes !''' For example:
+
* After the tag has propagated, clone your repo to make sure that no stray changes are put in the tarball. For example:
  svn co svn+ssh://svn.gnucash.org/repo/gnucash-docs/tags/2.4.1 r2.4.1
+
  cd ..
* Inside r2.4.1, run
+
rm -rf gnucash-docs-release
 +
git clone gnucash-docs -b 2.6 gnucash-docs-release
 +
* Inside gnucash-docs-release, run
 
  ./autogen.sh
 
  ./autogen.sh
  ./configure
+
  mkdir build
 +
cd build
 +
../configure
 
  make distcheck
 
  make distcheck
  
This should generate two tarballs, one bzip2 compressed and one gzip compressed. (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.)
+
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.) '''N.B.''' If a retag was necessary be sure to modify the tarball name to match so that it the automatic build scripts can find it.
 +
 
 +
== 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.
 +
 
 +
Building these requires the [https://xmlgraphics.apache.org/fop/ Apache FOP (XML Formatting-objects Processor)] for PDF and [http://calibre-ebook.com/ Calibre ] for mobi ebooks.
  
== Windows Executable ==
+
* In the same build directory we created in the previous step, run
The creation of the svn tag in the first section will automatically trigger the build for the Windows Executable in the next nightly build. The resulting executable can be downloaded the day after from http://code.gnucash.org/builds/win32
+
../configure --with-mobi
 +
make html pdf epub mobi
  
== Mac OS X Executable ==
+
This should generate the various alternative formats in subdirectories per document (guide or help) and per language (like C, de, it and so on).
This package is usually created by [[User:Jralls | John Ralls]] using this [[MacOSX/Quartz#Making_a_distribution | procedure]] .
 
  
 
== Sourceforge file uploads ==
 
== Sourceforge file uploads ==
All the above build targets should be uploaded to Source Forge.
+
The tarball generated above should be uploaded to Source Forge.
 
* Log in on the [[https://sourceforge.net/projects/gnucash/ Source Forge GnuCash website]]
 
* Log in on the [[https://sourceforge.net/projects/gnucash/ Source Forge GnuCash website]]
 
* Go to the Project Admin -> File Manager section
 
* Go to the Project Admin -> File Manager section
* Create a new directory for the release, either under gnucash (stable) or gnucash (unstable)
+
* Create a new directory for the release under gnucash-docs
* Upload the files created above to this directory.
+
* Upload the file created above to this directory.
* If this release is the latest stable release, mark these files as the default download targets for their respective platforms (.exe file on Windows, .dmg file on Mac OS X, source tarball on all other targets).
 
  
== GnuCash Website ==
+
== Git housekeeping after a release ==
=== 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.
+
If any changes were committed during the release steps above, merge these upwards to the other upstream branches. For example if you committed something to maint, merge maint into master:
* Check out subversion htdocs
+
  git checkout master
svn co svn+ssh://svn.gnucash.org/repo/htdocs/trunk/ gnucash-htdocs
+
  git merge maint
* 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 ===
+
Expect a merge conflict here for the changed version number. This is normal and the conflict should be resolved by keeping the version number in master. There may be other merge conflicts. Evaluate them and fix them accordingly.
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.
+
If the release was from an older maint-X.Y branch, merge these changes into maint and then merge maint into master. Expect the same version number conflict during the merges.
svn ci -m "Update to release x.y.z"
 
  
The commit will take care of updating the live website.
+
The first command creates a maintenance branch for the old stable release series. The subsequent commands move maint to where master is now. If the latter command fails there are commits on the maint branch that didn't get merged into master. This should not happen if the earlier steps were followed to verify ''master'' is a superset of ''maint''.
  
== Mailing list announcement ==
+
== GnuCash Website ==
 +
=== Uploading the new documentation versions ===
  
Send the same announcement to the following lists:
+
The additional documentation formats have to be uploaded to the gnucash website. The website is also managed in git, so to get the documentation in there, the current website sources have to be checked out:
* gnucash-devel@gnucash.org
+
* Move one level up from the gnucash-docs-release directory created above
* gnucash-user@gnucash.org
+
  git clone ssh://code.gnucash.org/gnucash-htdocs-docs
* 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.
+
You should now have the gnucash-docs-release and gnucash-htdocs-docs directories next to each other. Inside the htdocs-docs directory you will find a subdirectory docs and in there a subdirectory per major release (v1.8, v2.0, v2.2,...).  
 +
Note that each version directory starts with a lowercase "v" (from "version")
  
== Bugzilla ==
+
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/gnucash-htdocs-docs/v2.6"
 +
(cd gnucash-docs-release/build/guide; for i in C de it ja pt; do rsync -av --delete $i/gnucash-guide{,.pdf,.epub,.mobi} $base/$i/;done)
 +
(cd gnucash-docs-release/build/help; for i in C de it pt; do rsync -av --delete $i/gnucash-help{,.pdf,.epub,.mobi} $base/$i/;done)
  
Add the new version number.
+
You should find in the gnucash-htdocs-docs directory a shell script named <tt>copy-files.sh</tt> which does the rsync for you:
 +
  ./copy-files.sh /path/to/build_dir v2.6
 +
'''N.B.:''' The path must be absolute for it to work correctly.
  
 +
Note that the commands should be run from the parent directory of gnucash-docs-release and gnucash-htdocs, and the parentheses are important.
  
* Check if gnucash/DOCUMENTERS both trunk and stable is in sync with gnucash-docs/AUTHORS.
+
If that worked well, you can now go into the gnucash-htdocs-docs directory and use '''git add''' to add new files and '''git rm''' to remove deleted files from the repository (if any):
 +
cd gnucash-htdocs-docs
 +
git status
 +
# This will show a list of new/changed/deleted files.
 +
git add v2.6
 +
git rm [deleted files]...
 +
git commit -m "Add documentation version 2.6.2 to the GnuCash website"
 +
git push origin <branch>

Revision as of 00:14, 8 September 2019

This page gathers the steps for a release of the GnuCash documentation. It was animated by Bug 652350 - Formalize the Documentation release process.

URLs

URL Meaning
ssh://code.gnucash.org/gnucash-docs source files of the docs
ssh://code.gnucash.org/gnucash-htdocs-docs ready docs to be presented at ...
ssh://code.gnucash.org/gnucash-htdocs source files of www.gnucash.org

Releases

Beginning with 2.6.0, documentation releases should be done at the same time as GnuCash releases, with the Documentation release number corresponding to the GnuCash release. Do this even if there are no significant documentation changes in order to keep the numbers synchronized.

Branching Policy

As with development, we maintain two documentation branches, master and maint for whatever the current stable version is (at this writing it's 2.6).

  • Documentation updates describing features which are exclusively in code's master branch should be applied only on master.
  • All others should be applied on maint and then merged in master.

Check Git#Branching and Merging to see if something changed.

Major Releases

A major release is the first release to bring new development features to the users. This is shown by a jump in the version number (for example from 2.6.x to 2.8.0), and signifies the start of a new major development cycle.

git

This means the branches in our repository have to be reshuffled. The release is done from a commit on the master branch. This commit should now become the HEAD commit for the maint branch because maintenance should now happen from there on. At the same time it may be necessary to keep up maintenance to the previous major series, so this should now get its own branch.

 git branch maint-X.Y maint # for example git branch maint-2.6 maint
 git checkout maint
 git merge --ff-only master


docbook/gnc-docbook.dtd
Update <!ENTITYs vers-unstable ... series-stable.

GnuCash Wiki

This is now done by templates, see Release_Process#Update_Release_Version.

Website

Create a new directory for the documentation in the website repo:

 mkdir v5
 git add v5

Checkout release branch

  • Determine which branch to do the release from:
    • If you want to release a new maintenance release on the current stable series (like 2.6.1, 2.6.2,...) then choose maint
    • If you want to release a new maintenance release on an older stable series (like 2.4.16 if 2.6.x is the current stable series) then choose maint-X.Y
    • If you are about to release a development snapshot (like 2.7.0, 2.7.1,...), choose master
  • Clone gnucash-docs if you don't already have one.
 git clone ssh://code.gnucash.org/gnucash-docs
  • Check out the branch you want and make sure that it's up-to-date:
 cd gnucash-docs
 git checkout <branch>
 git pull --rebase

If you are about to release from master you should verify that master is a superset of maint. You can do this by running the following command

 git log master..maint

This command should not list any commits. If it does, checkout master and merge maint into it.

 git checkout master
 git merge maint
Note
The same check should be performed when releasing from maint and there is an older maint-X.Y branch on which commits still happen.

Checks and Updates

docbook/gnc-docbookx.dtd
Update <!ENTITYs manrevision and date.
  • In each copy of gnucash-help.xml and gnucash-guide.xml, update the document history.
  • Update the copyright - the year might change.
  • 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 on both development and stable branches is in sync with gnucash-docs/AUTHORS.
  • Update the version number of the [AC_INIT] macro in configure.ac
  • Update NEWS by running ../gnucash/util/git-release-notes.pl > release.news and copying over the changes, reformatting appropriately.
  • Update the ChangeLog:
 git log --format="%ad %aN %n%n%x09* %s%d%n" --date=short <previous release tag>.. > ChangeLogNew
 mv ChangeLog ChangeLogOld
 cat ChangeLogNew ChangeLogOld > ChangeLog
 rm ChangeLogNew
 rm ChangeLogOld 
  • Commit this change as "Release X.X.X"

Git

  • Verify that the chosen branch can build a distribution tarball, compile, and test it satisfactorily:
./autogen.sh
./configure
make distcheck
Fix any errors this step may turn up, commit and check again.
  • Tag the release and push:
 git tag -am "Release 3.4" 3.4
 git push --tags origin <branch>

N.B. If after pushing the tag you discover a problem, fix the problem and tag the new commit with a lower-case letter subscript, e.g.

  git -tag -am "Re-tag of release 3.4" 3.4a

Source tarballs

  • After the tag has propagated, clone your repo to make sure that no stray changes are put in the tarball. For example:
cd ..
rm -rf gnucash-docs-release 
git clone gnucash-docs -b 2.6 gnucash-docs-release
  • Inside gnucash-docs-release, 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.) N.B. If a retag was necessary be sure to modify the tarball name to match so that it the automatic build scripts can find it.

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.

Building these requires the Apache FOP (XML Formatting-objects Processor) for PDF and Calibre for mobi ebooks.

  • 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, it and so on).

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.

Git housekeeping after a release

If any changes were committed during the release steps above, merge these upwards to the other upstream branches. For example if you committed something to maint, merge maint into master:

 git checkout master
 git merge maint

Expect a merge conflict here for the changed version number. This is normal and the conflict should be resolved by keeping the version number in master. There may be other merge conflicts. Evaluate them and fix them accordingly.

If the release was from an older maint-X.Y branch, merge these changes into maint and then merge maint into master. Expect the same version number conflict during the merges.

The first command creates a maintenance branch for the old stable release series. The subsequent commands move maint to where master is now. If the latter command fails there are commits on the maint branch that didn't get merged into master. This should not happen if the earlier steps were followed to verify master is a superset of maint.

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 git, so to get the documentation in there, the current website sources have to be checked out:

  • Move one level up from the gnucash-docs-release directory created above
 git clone ssh://code.gnucash.org/gnucash-htdocs-docs

You should now have the gnucash-docs-release and gnucash-htdocs-docs directories next to each other. Inside the htdocs-docs directory you will find a subdirectory docs and in there a subdirectory per major release (v1.8, v2.0, v2.2,...). 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/gnucash-htdocs-docs/v2.6"
(cd gnucash-docs-release/build/guide; for i in C de it ja pt; do rsync -av --delete $i/gnucash-guide{,.pdf,.epub,.mobi} $base/$i/;done)
(cd gnucash-docs-release/build/help; for i in C de it pt; do rsync -av --delete $i/gnucash-help{,.pdf,.epub,.mobi} $base/$i/;done)

You should find in the gnucash-htdocs-docs directory a shell script named copy-files.sh which does the rsync for you:

 ./copy-files.sh /path/to/build_dir v2.6

N.B.: The path must be absolute for it to work correctly.

Note that the commands should be run from the parent directory of gnucash-docs-release and gnucash-htdocs, and the parentheses are important.

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

cd gnucash-htdocs-docs
git status
# This will show a list of new/changed/deleted files.
git add v2.6
git rm [deleted files]...
git commit -m "Add documentation version 2.6.2 to the GnuCash website"
git push origin <branch>