Releases and Patching: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
Line 45: Line 45:
*** in that case it is best to simply copy an existing file that also contained no DB changes.
*** in that case it is best to simply copy an existing file that also contained no DB changes.
* modify file <code>version.txt</code> in directory db/patches so it contains the Version Number of the OpenPetra release that you are creating.
* modify file <code>version.txt</code> 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
** Alternative: use the parameter -D:ReleaseID=0.0.2.0 for specifiying the build number, when running nant buildWindowsStandalone in step [[Releases and Patching#Installers | Installers]].


====Final Steps====
====Final Steps====

Revision as of 09:05, 5 November 2012

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

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 in step Installers.

Final Steps

Bazaar
  • Tag trunk with the name of the new release (e.g. ALPHA-0.2.22)
Installers
  • 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)
    • Installers end up in the /delivery/ directory.
  • Test installers on Windows and Linux.
  • Upload all installers to SourceForge using a 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.2.16.0 from /setup/tools/ for that

Patches

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