Difference between revisions of "Release Process"
(→Updating the release number for the download pointers: Needs http://sourceforge.net/projects/gnucash/files/ a separate update?) |
(→Updating the release number for the download pointers) |
||
Line 66: | Line 66: | ||
The commit will take care of updating the live website. | The commit will take care of updating the live website. | ||
− | '''Q:''' Needs http://sourceforge.net/projects/gnucash/files/ a separate update? | + | '''Q:''' Needs http://sourceforge.net/projects/gnucash/files/ a separate update? (cstim: What do you mean by that? If you mean the "default download" button, this is handled by the last point above in the sf upload instructions: "Mark this file as the default...") |
== Mailing list announcement == | == Mailing list announcement == |
Revision as of 08:03, 5 April 2013
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.
Contents
Backport Policy
Check the Subversion#Current_Backport_Policy.
Subversion
- Check out Subversion trunk.
- Verify that current trunk 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
- Commit this change in subversion
- Copy the subversion trunk to the tags/<version-number>. For example:
svn cp svn+ssh://svn.gnucash.org/repo/gnucash/trunk svn+ssh://svn.gnucash.org/repo/gnucash/tags/2.3.10 -m "Tag 2.3.10"
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/tags/2.3.10 r2.3.10
- Inside r2.3.10, run
./autogen.sh ./configure 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.)
Windows Executable
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
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)
- 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).
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.
Q: Needs http://sourceforge.net/projects/gnucash/files/ a separate update? (cstim: What do you mean by that? If you mean the "default download" button, this is handled by the last point above in the sf upload instructions: "Mark this file as the default...")
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
After logging in
- Add the new version number and eventually
- add the next milestone.