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
• run nant uncrustify since nant translation reformats some of the code and the changed source code files might not conform to our uncrustify rules.
• Commit to Launchpad trunk using Bazaar.

Mantis Tracker

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

We need to make sure that every developer has set "Fixed in Version" on all the bugs that have 'Closed' or 'Resolved' state. As this is normally forgotten on quite a few bugs, it must be done manually before a release in order to have a complete list of bugs that were fixed in this release.

• 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.
  • In both steps, make a note of all bug numbers that have been 'closed'/'resolved' since the date of the last release.
• Run the MantisUpdateVersions Tool
  • The tool resides in \setup\tools\MantisUpdateVersions</code. 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, the string that follows after '-version-fixed-in:' with the current release number and abc,def,ghi with the 1..n Mantis Bug ID's that you found in the two Mantis filter steps.
    • NOTE: The SourceForge user that is specified in this command needs to have 'administrator' privileges in the Mantis Bugtracker so that the commands that are issued by this program can succeed!

Creating Static 'Bugs Resolved in this Release' HTML File

We need to create a static HTML page that contains the list of all bugs that got resolved/closed in this release. This page gets uploaded to SourceForge and is linked to from the Release Notes and News Updates.

• Simply filtering Mantis and creating a permalink [using the 'Create Permalink' functionality on the search result page] does not work with Mantis in the version that is used on Sourceforge!
• Instead, do the following:
  • In FireFox (Chrome is bad with external links),
    • go to https://sourceforge.net/apps/mantisbt/openpetraorg/view_all_bug_page.php,
    • create the follwing Filter:
      • fixed in version 0.0.2.0 [use current release number],
      • hide none (thus the list will includes resolved and closed bugs)
  • Click on Print, and store the file in some local directory
• Upload that file to eg. http://openpetraorg.sourceforge.net/ReleaseDetails/BugsFixed_Alpha-0.2.8.htm [use current release number] using some FTP program (directory username/openpetraorg@web.sourceforge.net:/home/project-web/openpetraorg/htdocs/ReleaseDetails).

Release Notes

• Update Release notes files in setup/petra0300/releasenotes. (English: releasenotes.html, German: releasenotes_de.html)
  • Format:
    • never empty the contents of that file as it is meant to be cumulative!
    • rather, add the Release Notes that pertain to the current release on top of the file.
    • follow the format of the previous Release Notes.
• Commit the changed files to Launchpad trunk using Bazaar.

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 commandline argument -D:ReleaseID=0.0.2.0 [use current release number] to specify the build number when running nant buildWindowsStandalone in step Installers.

Final Steps

Bazaar

• Tag trunk with the name of the new release (e.g. ALPHA-0.2.22 [use current release number])

Installers

• On a windows machine: run nant buildWindowsStandalone -D:ReleaseID=0.0.2.0 [use current release number]
• On a linux machine: run nant buildLinuxSourceforgeRelease -D:ReleaseID=0.0.2.0 [use current release number].
  • bzr update, bzr revert. (on openpetrabuild: /home/timop/bzr)
  • Installers end up in the /delivery/ directory.
• Test installers on Windows and Linux.
• Upload all installers to SourceForge using some FTP program: username@frs.sourceforge.net:/home/pfs/project/o/op/openpetraorg/openpetraorg

Making the Release Known to the Public

Website

• Release Notes
  • Post Release Notes on the 'Download' page of the website (English, German).
    • Format of the Release Notes: refer to previous posts.
    • Include download link for the Windows Installer and the Linux packages that pertain to this release.
    • Include link to the static HTML file that contains the list of closed bugs that pertains to this release (created in an earlier step in these instructions).
• News Update
  • If there is a News Update that corresponds with the release (which often is the case): post news update in the 'News' section of the website (English, German).
    • Format of the News Update: refer to previous posts.
    • Include link to the 'Download' page of the website (English, German).

Notifications

• Send out a 'Tweet' on Twitter
  • Tweet about the release on twitter (English [user: openpetraorg], German [user: openpetraorgde])
  • Format of the Tweet: refer to previous tweets that pertain to releases.
• Mailing Lists
  • Send out information on mailing lists (English, German).
    • Content of the emails: exactly the same as in the tweets - except if there is a News Update that corresponds with the release: in this case the content of what got posted in the 'News' section of the website.

Mantis Tracker

• Next Release needs to be added to all projects
  • as this is tedious if done manually use the tool MantisUpdateVersions.exe -sf-username:pokorra -sf-pwd:*** -release-version:0.0.2.0 from /setup/tools/ for that [use current release number]

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';"