Releases and Patching

Releases

The deliverables are:

• the tar.gz files (server-debian-postgresql, server-debian-centos, client) which could be the base for manual installs, and for RPMS
• the standalone installer for Windows
• the remote client installer for Windows (not published on Sourceforge, since it would be bound to an IP address)
  • a special tar.gz file that is used as a base for building the patches (see below)

Things todo for a SourceForge release

Update translations from/to Launchpad

• Download the latest language files from Launchpad using nant translation
  • Adding new languages (if desired)
    • New languages might have been downloaded after running nant translation. These would show up in the 'Unversioned' section of Bazaar Explorer. If we really want to add one of those new languages to OpenPetra then perform these steps:
      • Add DLL in section '[Files]' in file setup\petra0300\standalone\standalone.iss;
        • e.g. Source: ..\..\..\delivery\bin\es-ES\OpenPetra.resources.dll; DestDir: {app}/bin30/es-ES for Spanish
      • Add language at task 'downloadTranslations' in file i18n\i18n.build;
        • e.g. <move file="${dir.root}/i18n/de.po" tofile="${dir.root}/i18n/de-DE.po"/> for German
      • Bazaar-Add the language file that is showing in the 'Unversioned' bazaar section so it is under Version Control.
• Generate the latest translation template using nant buildTranslationTemplate
• before commit, please run nant uncrustify, since nant translation reformats some of the code which is not according to our uncrustify rules.
• Commit to Launchpad trunk using Bazaar.

Ensuring that all fixed Bugs have set "Fixed in Version"

We need to make sure that everyone has set "Fixed in Version" on all the bugs that have 'Closed' or 'Resolved' state

• Using Mantis,
  • filter for all bugs with 'closed' and 'resolved' state that have 'Fixed in Version' equals 'none', 'Resolution' equals 'fixed' and 'Hide Status' equals 'None'.
  • do the same for 'resolved' state on a new Tab of your web browser.
• Run the MantisUpdateVersions Tool
  • The tool resides in \setup\tools\MantisUpdateVersions. As it isn't get built by nant generateSolution you need to load the C# Project 'MantisUpdateVersions.csproj' into your favourite IDE and compile it.
  • Open a command shell and change the directory to '...\setup\tools\MantisUpdateVersions\obj\x86\Debug'
  • Execute the following command: MantisUpdateVersions.exe -sf-username:pokorra -sf-pwd:xyz -bug-id:abc,def,ghi -version-fixed-in:"Alpha 0.2.20", replacing the value for -sf-username and -sf-pwd with your SourceForge username and password and abc,def,ghi with the 1..n Mantis Bug ID's that you found at the Mantis filter step.
  • NOTE: The SourceForge user that is specified in this command needs to have 'administrator' privileges in the Mantis Bugtracker!

Release Notes

• Release Notes: the permalink does not work for Sourceforge Mantis
  • In Firefox (Chrome is bad with external links), go to https://sourceforge.net/apps/mantisbt/openpetraorg/view_all_bug_page.php, filter: fixed in version 0.0.2.0, hide none (includes closed and resolved bugs)
  • click on print, and store the file
  • upload to eg. http://openpetraorg.sourceforge.net/ReleaseDetails/BugsFixed_Alpha-0.2.8.htm (username/openpetraorg@web.sourceforge.net:/home/project-web/openpetraorg/htdocs/ReleaseDetails)
• Update Release notes in bzr, setup/petra0300/releasenotes

DB Patches

• add new patch sql file to db/patches
  • this only applies to increased patch numbers, not builds! so the patch sql file will always be for version.release.patch-0, where 0 is the build number.
  • file with new version number needs to exist even if there were no DB changes!
    • in that case it is best to simply copy an existing file that also contained no DB changes.
• modify file version.txt in directory db/patches so it contains the Version Number of the OpenPetra release that you are creating.
  • Alternative: use the parameter -D:ReleaseID=0.0.2.0 for specifiying the build number, when running nant buildWindowsStandalone

Further Steps

• Tag bzr

• On a windows machine: run nant buildWindowsStandalone -D:ReleaseID=0.0.2.0
• On a linux machine: run nant buildLinuxSourceforgeRelease -D:ReleaseID=0.0.2.0. bzr update, bzr revert. (on openpetrabuild: /home/timop/bzr)
• test installer on Windows and Linux

• Upload to SF: username@frs.sourceforge.net:/home/pfs/project/o/op/openpetraorg/openpetraorg
  • link the release notes
• Post Release Notes on website, twitter (english, german)
• Send out information on mailing lists (english, german)
• Update Mantis Tracker:
  • add next release to all projects
  • use the tool MantisUpdateVersions.exe -sf-username:pokorra -sf-pwd:*** -release-version:0.2.16.0 from setup/tools/

Patches

• we use the bsdiff algorithm from http://www.daemonology.net/bsdiff/ for binary diffs and patching
• see more about the patchtool

patching the database

Standalone:

• standalone is always delivered with SQLite database
• we don't have patch installers yet. a full installer will update the program files, and add sql files for patching the database (setup\petra0300\standalone\patches). We cannot write to the user's directory, since the installer must be run as admin.
• on the next startup of OpenPetra Standalone by the user, csharp\ICT\Petra\Server\app\Main\ServerManager.cs EstablishDBConnection() will check for the database version, and UpdateSQLiteDatabase() will update the sqlite database
• this will also run "UPDATE s_system_defaults SET s_default_value_c = '{0}' WHERE s_default_code_c = 'CurrentDatabaseVersion';"