Difference between revisions of "Release Process"

Revision as of 19:52, 15 December 2014

Each GnuCash release involves a number of steps for the release manager. This page is intended to gather these steps for the program, while the Documentation Release Process is separated.

Commit Policy

Check Git#Branching and Merging.

Release Process

Notes

• Where relevant, the process below assumes that the primary git repository is configured as a remote called "upstream". If you have configured it under another name, please adapt the commands below accordingly.

Source preparation

• Check out Git branch you wish to release. Typical candidates are master, maint or any maint-X.Y. For example

git checkout master
git pull --rebase

• Check translations at the Translation Project Gnucash page for updates and apply any that haven't been already committed, e.g. as suggested in translationprojects maintainers page.

The translation project recommends using

rsync -Lrtvz  translationproject.org::tp/latest/gnucash/  po

But that doesn't always return the latest files. One can instead use

 for i in eu ca zh_CN cs da nl ja fa pt sk sv uk; do wget -O $i.po  http://translationproject.org/PO-files/$i/gnucash-2.6.4.$i.po; done

Substituting the last version of GnuCash for '2.6.4'.

Next, check syntax and get the statistics:

cd po

for i in *.po; do echo -n "$i:"; msgfmt -c --statistics $i;done

• Note

  These should probably applied to the oldest branch for which you expect do do releases still which may not be the branch you want to release now from. If this is the case apply them to the proper branch (eg maint) and merge upwards to your branch (eg master).

• 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.

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

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.

• Update the version number of the [AC_INIT] macro in configure.ac
• Run

  util/gitlog2ul.sh <previous release> > release.News

and summarize significant changes in a release summary in NEWS.

• If this is the first release of a calendar year:
  • copy ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
  • In makefile.am:
    • Add ChangeLog.YYYY to dist_doc_DATA,
    • Find the rule to generate the ChangeLog, update the "--since" parameter to the start of the current year.
• Run make, which should update the ChangeLog file now.
• If you are building out of tree, copy the updated ChangeLog from your build directory to your source directory.
• Commit changes to NEWS and the ChangeLogs to the git repository. Don't forget to add the new ChangeLogs first if it's the start of a new year.
• Push all your changes to upstream:

git push upstream master:master

• Tag the new release.

For example:

git tag -am "Tag 2.5.2" 2.5.2
git push upstream --tags

Source tarballs

• Checkout the release tag from git. Either clone or clean your git repo here to avoid packaging unreleased changes ! For example:

git clone <your-local-up-to-date-git-repo> r2.5.2
cd r2.5.2
git checkout 2.5.2

or, while inside your local repo

git clean -fdx

• Now run

./autogen.sh
mkdir build
cd build
../configure
make distcheck
sha256sum gnucash-2.5.2.tar.* > README

This should generate two tarballs, one bzip2 compressed and one gzip compressed, along with a README file containing the sha256 hashes. Using make distcheck performs several checks on the distribution before making the tarballs, then decompresses one of them, builds it, and runs make check on the results which ensures that everything is properly packaged for distribution.

A user pointed out on IRC that SourceForge not only doesn't use https but also generally redirects the user to a third-party mirror to provide the download. He was concerned that an attack is possible in that insecure environment. Accordingly, we also make checksums and put them in the README so that SourceForge will display them on the download page. By using a build directory you avoid overwriting the source README.

Documentation

Now make a documentation release using the same version number as you set above for GnuCash. See Documentation Release Process for the procedure.

Windows Executable

The creation of the 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

Mac OS X Executable

This package is usually created by John Ralls using this procedure .

Sourceforge file uploads

All the above build targets 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, either under gnucash (stable) or gnucash (unstable). Mark it "staged" in either the creation or the info dialog.
• Upload the files 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).
• When everything is ready, open the info dialog for the containing directory and clear the staged check-box. Note that if the release runs into problems that take more than 3 days you may need to renew the "staged" flag.

Git housekeeping after a release

All releases

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.

A major release

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.

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.

In git:

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

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

Note that gnucash-htdocs is a pure git repository. In order to update the website you will hence have to follow the instructions on our Git wiki page to prepare a local gnucash-htdocs repository with commit access to the primary repository on code.gnucash.org. Be sure to follow the committer instructions for pure git repositories on that page !

Adding the announcement text

• Checkout the master branch and make sure it's up to date

cd gnucash-htdocs.git
git checkout master
git pull upstream

• Go to the news files

cd news

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

cp 130430-2.5.1.news 130527-2.5.2.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.5.1/2.5.2/g' 130527-2.5.2.news
sed -i -e 's/2.5.0/2.5.1/g' 130527-2.5.2.news

• Open the new file in your favorite editor. Using the NEWS files you created for GnuCash and GnuCash Documentation as a basis, revise the announcement to reflect the changes in this new release.
• Add the new file to revision control

git add 130527-2.5.2.news

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. From the base directory:

git add <changed-files>
git commit -m "Update to release x.y.z"
git push upstream master:master

The last command will take care of updating the live website.

Mailing list announcement

Send the same announcement to the following lists:

• gnucash-user@gnucash.org
• BCC gnucash-devel@gnucash.org
• BCC 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. This works in Apple Mail as well.

The BCCs are to prevent reply-alls from being copied to those lists.

Translation Project

Email a link of the release tarball to coordinator@translationproject.org.

Bugzilla

After logging in

• Add the new version number and eventually
• add the next milestone.

Release Schedule

Add the actual release date to Release Schedule.

New Major/Minor Version

The culmination of each development cycle is the release of a new series with a new minor, and perhaps a new major, version number. Preparation for this release is typically a six-month alpha/beta release project with some special milestones.

Version Numbers

GnuCash uses a three-part version number: Major, Minor, and Micro. Major version numbers are changed rarely and only after major architectural changes to GnuCash. Minor versions are changed when preparing a new stable series from the development, or master, branch. Unstable releases are given an odd minor version, stable releases an even minor version number. Micro version numbers are assigned sequentially to each release in a series.

Freezes

In order to allow time for thorough testing and localization, it's important to set aside some development activities during the run up to a stable release. The dates that those activities stop are traditionally called freezes.

• Feature Freeze: No new features or significant architectural changes should be committed after this date to ensure that there's adequate time for the more adventurous users who act as our testers to try everything out and provide feedback.
• String Freeze: No new user-visible strings should be added after this date in order to allow translators time to finish their work by the final release date. The Translation Project requests at least two weeks, but practice suggests that a month or more is better.
• Code Freeze: Slightly misnamed, this means that only code fixing critical bugs and of limited scope, so that it's unlikely to cause regressions in other parts of the program, should be committed.

Release Schedule and Milestones

• Monthly test releases should begin 6 months before the target release date.
• The team should determine dates for feature and string freeze, and publish them on the Release Schedule.
• the Translation Project Coordinators should be notified of the first release after string freeze by emailing a link to the tarball to coordinator@translationproject.org.
• After Code Freeze test release frequency should increase to weekly. The announcements for these releases should inform testers that they are release candidates.