Difference between revisions of "Release Process"

From GnuCash
Jump to: navigation, search
(→‎Subversion: Update NEWS and ChangeLog before tagging.)
(Rework process for releasing from a git repository and simplify ChangeLog generation steps.)
Line 4: Line 4:
 
Check the [[Subversion#Current_Backport_Policy]].
 
Check the [[Subversion#Current_Backport_Policy]].
  
−
== Subversion ==
+
== Git Based Release ==
 +
 
 +
These steps detail how to perform a GnuCash release from a GnuCash git repository. This is only possible from 2.5.2 and up. for older releases check out the [[#Svn Based Release]] steps below.
 +
 
 +
''Note'': as of this writing, svn is still the master repository. This impacts the way releases are tagged. So even though we start from a git repo, the full release process requires a few svn commands to be executed. These will be marked with '''SVN-MASTER''' below to make clear these will are only required as long as the svn repository is still the master repository. The alternative commands to execute once our code.gnucash.org git repo is master will be prefixed with '''GIT-MASTER''', but should not be used yet ! The expected data to switch master repository is at the release of gnucash 2.6.
 +
 
 +
=== Git ===
 +
* Check out [[Git]] 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 <tt>[AC_INIT]</tt> macro in <tt>configure.ac</tt>
 +
* If this is the first release of a calendar year, copy ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
 +
* Find the rule in Makefile.am to generate the ChangeLog, update the "--since" parameter to the start of the current year.
 +
* Run
 +
  util/gitlog2ul.sh <previous release> > release.News
 +
and summarize significant changes in a release summary in NEWS.
 +
* 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
 +
'''SVN-MASTER''':
 +
git svn dcommit
 +
''''GIT-MASTER''' (assuming you have code.gnucash.org's repo configured as 'origin'):
 +
git push origin trunk:trunk
 +
* Tag the new release.
 +
'''SVN-MASTER''' This is done by copying trunk to tags/<version-number> in the subversion repository. 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"
 +
'''GIT-MASTER''' For example:
 +
git tag "Tag 2.3.10"
 +
git push origin --tags
 +
FIXME Does git tagging require more options ?
 +
* '''SVN-MASTER''' Get the latest tag in your local git repository:
 +
  git checkout trunk
 +
  git update
 +
  git fetch -t
 +
 
 +
 
 +
=== Source tarballs ===
 +
* Checkout the release tag from git. '''Clone your git repo here to avoid packaging unreleased changes !''' For example:
 +
git clone <your-local-up-to-date-git-repo> r2.3.10
 +
cd r2.3.10
 +
git checkout 2.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 git 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 [[User:Jralls | John Ralls]] using this [[MacOSX/Quartz#Making_a_distribution | procedure]] .
 +
 
 +
=== Sourceforge file uploads ===
 +
All the above build targets should be uploaded to Source Forge.
 +
* Log in on the [[https://sourceforge.net/projects/gnucash/ 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 git source directory
 +
* Run the 'gitlog2ul.sh' utility to get the commit messages relevant to this release. For example:
 +
./util/gitlog2ul.sh 2.3.9 2.3.10 > 2.3.10-commits.html
 +
 
 +
Use the output together with a previous news file to generate a news message for this release. The easiest way is probably to copy the old news file 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 not set up yet, follow [[Git|these instructions]] to clone the htdocs git repository first. The instructions explain setting up git for the main GnuCash repository, but can easily be adapted to clone the htdocs repository as well. Just replace the repository names with htdocs (whenever the svn repo is referenced) or gnucash-htdocs (whenever the git repo is referenced)
 +
* Checkout the trunk branch in the htdocs repository
 +
cd gnucash-htdocs.git
 +
git checkout trunk
 +
* Go to the news files
 +
cd news
 +
* Copy the last release newsfile. The filename format is usually YYMMDD-<releasenumber>.news. For example:
 +
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)
 +
* Add the new file to revision control
 +
git add 100316-2.3.11.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"
 +
'''SVN-MASTER''':
 +
git svn dcommit
 +
'''GIT-MASTER''' (assuming you have code.gnucash.org's repo configured as origin):
 +
git push origin trunk:trunk
 +
 
 +
The last command 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...")
 +
 
 +
== Svn Based Release ==
 +
 
 +
Prior to GnuCash 2.5.2 all releases were done starting from the svn repository. This uses slightly different commands than the git repository based release.
 +
 
 +
=== Subversion ===
 
* Check out [[Subversion]] trunk.
 
* Check out [[Subversion]] trunk.
 
* Verify that current trunk can build a distribution tarball, compile, and test it fine:
 
* Verify that current trunk can build a distribution tarball, compile, and test it fine:
Line 10: Line 116:
 
: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.
 
: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 <tt>[AC_INIT]</tt> macro in <tt>configure.ac</tt>
 
* Update the version number of the <tt>[AC_INIT]</tt> macro in <tt>configure.ac</tt>
−
* If this is the first release of a calendar year, rename ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
+
* If this is the first release of a calendar year:
−
* Run
+
:* copy ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
−
  svn log -rHEAD:<previous release's revision> --xml --verbose | xsltproc macros/svn2cl.xsl - > ChangeLog.new
+
:* Find the rule in Makefile.am to generate the ChangeLog, update the "-r" parameter for the svn log command to range from 'HEAD:<first-commit-of-this-year>'. You could look up the revision number of that first commit and use that (old way), or you can set this range to 'HEAD:{<start-of-year-date>}' like for example 'HEAD:{2013-01-01}'. The last option is simpler at the cost of one revision too much in the log file.
−
and paste the result to the top of ChangeLog. You can use
 
−
  svn info svn+ssh://svn.gnucash.org/repo/gnucash/tags/<previous release>
 
−
where <previous release> is the tag name, e.g. <tt>2.5.0</tt>, to discover the revision number.
 
 
* Run
 
* Run
 
   util/svnlog2ul/svnlog2ul.sh <previous release> > release.News
 
   util/svnlog2ul/svnlog2ul.sh <previous release> > release.News
−
and summarize significant changes in a release summary in NEWS.  
+
and summarize significant changes in a release summary in NEWS.
−
* Commit this change in subversion. Don't forget to add the new ChangeLogs first if it's the start of a new 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 subversion repository. Don't forget to add the new ChangeLogs first if it's the start of a new year.
 
* Copy the subversion trunk to the tags/<version-number>. For example:
 
* 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"
 
  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 ==
+
=== Source tarballs ===
 
* Checkout the release tag from subversion. '''Do a clean checkout here to avoid packaging unreleased changes !''' For example:
 
* 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
 
  svn co svn+ssh://svn.gnucash.org/repo/gnucash/tags/2.3.10 r2.3.10
Line 33: Line 138:
 
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.)
 
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 ==
+
=== 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
 
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 ==
+
=== Mac OS X Executable ===
 
This package is usually created by [[User:Jralls | John Ralls]] using this [[MacOSX/Quartz#Making_a_distribution | procedure]] .
 
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.
 
All the above build targets 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]]
Line 47: Line 152:
 
* 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).
 
* 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 ==
+
=== GnuCash Website ===
−
=== Adding the announcement text ===
+
==== Adding the announcement text ====
 
* Go to your GnuCash svn source directory
 
* Go to your GnuCash svn source directory
 
* cd util/svnlog2ul/
 
* cd util/svnlog2ul/
Line 66: Line 171:
 
* 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)
 
* 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 ===
+
==== 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.
 
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.
 
* 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.

Revision as of 09:58, 17 May 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.

Backport Policy

Check the Subversion#Current_Backport_Policy.

Git Based Release

These steps detail how to perform a GnuCash release from a GnuCash git repository. This is only possible from 2.5.2 and up. for older releases check out the #Svn Based Release steps below.

Note: as of this writing, svn is still the master repository. This impacts the way releases are tagged. So even though we start from a git repo, the full release process requires a few svn commands to be executed. These will be marked with SVN-MASTER below to make clear these will are only required as long as the svn repository is still the master repository. The alternative commands to execute once our code.gnucash.org git repo is master will be prefixed with GIT-MASTER, but should not be used yet ! The expected data to switch master repository is at the release of gnucash 2.6.

Git

  • Check out Git 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
  • If this is the first release of a calendar year, copy ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
  • Find the rule in Makefile.am to generate the ChangeLog, update the "--since" parameter to the start of the current year.
  • Run
  util/gitlog2ul.sh <previous release> > release.News

and summarize significant changes in a release summary in NEWS.

  • 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

SVN-MASTER: 

git svn dcommit

'GIT-MASTER (assuming you have code.gnucash.org's repo configured as 'origin'): 

git push origin trunk:trunk
  • Tag the new release.

SVN-MASTER This is done by copying trunk to tags/<version-number> in the subversion repository. 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"

GIT-MASTER For example: 

git tag "Tag 2.3.10"
git push origin --tags

FIXME Does git tagging require more options ?

  • SVN-MASTER Get the latest tag in your local git repository:
 git checkout trunk
 git update
 git fetch -t


Source tarballs

  • Checkout the release tag from git. Clone your git repo here to avoid packaging unreleased changes ! For example:
git clone <your-local-up-to-date-git-repo> r2.3.10
cd r2.3.10
git checkout 2.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 git 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 git source directory
  • Run the 'gitlog2ul.sh' utility to get the commit messages relevant to this release. For example:
./util/gitlog2ul.sh 2.3.9 2.3.10 > 2.3.10-commits.html

Use the output together with a previous news file to generate a news message for this release. The easiest way is probably to copy the old news file 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 not set up yet, follow these instructions to clone the htdocs git repository first. The instructions explain setting up git for the main GnuCash repository, but can easily be adapted to clone the htdocs repository as well. Just replace the repository names with htdocs (whenever the svn repo is referenced) or gnucash-htdocs (whenever the git repo is referenced)
  • Checkout the trunk branch in the htdocs repository
cd gnucash-htdocs.git
git checkout trunk
  • Go to the news files
cd news
  • Copy the last release newsfile. The filename format is usually YYMMDD-<releasenumber>.news. For example:
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)
  • Add the new file to revision control
git add 100316-2.3.11.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"

SVN-MASTER: 

git svn dcommit

GIT-MASTER (assuming you have code.gnucash.org's repo configured as origin): 

git push origin trunk:trunk

The last command 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...")

Svn Based Release

Prior to GnuCash 2.5.2 all releases were done starting from the svn repository. This uses slightly different commands than the git repository based release.

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
  • If this is the first release of a calendar year:
  • copy ChangeLog to ChangeLog.YYYY with YYYY being the previous year.
  • Find the rule in Makefile.am to generate the ChangeLog, update the "-r" parameter for the svn log command to range from 'HEAD:<first-commit-of-this-year>'. You could look up the revision number of that first commit and use that (old way), or you can set this range to 'HEAD:{<start-of-year-date>}' like for example 'HEAD:{2013-01-01}'. The last option is simpler at the cost of one revision too much in the log file.
  • Run
  util/svnlog2ul/svnlog2ul.sh <previous release> > release.News

and summarize significant changes in a release summary in NEWS.

  • 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 subversion repository. Don't forget to add the new ChangeLogs first if it's the start of a new year.
  • 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

Retrieved from "https://wiki.gnucash.org/wiki/index.php?title=Release_Process&oldid=9703"