Release Management

This page documents the suggested procedure to smoothly release a new version.

Before Release

Development (VCS HEAD)

Preparing X.Y.rcN release candidates

branch master

  • grep the tree for instances of the old database name and replace with the new one where appropriate
  • pycommon/
    • add hash of new database
    • teach it which database version to expect for the new client branch
  • create Inbox message with Release Notes via SQL script
  • include SQL upgrade scripts
  • download and merge any new translations from Launchpad
  • adjust client/gm-from-vcs.conf
  • create branch: git branch rc-X-Y

branch rc-X-Y

(wash/rinse/repeat as needed)

  • git checkout rc-X-Y
  • git merge master
  • update Inbox message with Release Notes
  • include latest database release
  • bootstrap-latest.conf: include latest upgrade-vN_vN+1.conf
  • upgrade-vN_vN+1.conf: expect new database version instead of devel
  • client/doc/make-*.sh scripts: refer to the proper databases
  • set proper database version and client version X.Y.rcN
  • wxpython/ set client version X.Y.rcN
  • test basic functionality (startup !)
  • tag tree: git tag rel-X-Y-rcN
  • re-publish manual
  • create tarball
  • publish Release Candidate in our download area
  • adjust gm-versions.txt
  • upgrade public database

Preparing the X.Y.0 release

  • git checkout master

  • refer to the latest database version
  • include latest database release
  • bootstrap-latest.conf: include latest upgrade-vN_vN+1.conf
  • updates release notes SQL script and set version numbers from .rcN zu X.Y.0
  • in CHANGELOG set version numbers from .rcN zu X.Y.0
  • create empty fixup_db-vNN.conf (so that gm-fixup_server doesn't fail even if useless)
  • git commit -v

Create rel-X-Y:

  • git branch tmp
  • git checkout tmp
  • git merge rc-X-Y
  • git merge --abort and fix any problems in master and/or rc-X-Y
  • retry git merge rc-X-Y until it works
  • git checkout master
  • git branch -d tmp
  • git tag -s rel-X-Y
  • git branch rel-X-Y-patches rel-X-Y (create a branch from that tag)
  • git checkout rel-X-Y-patches
  • git merge rc-X-Y
  • git branch -d rc-X-Y
  • activate "tarball release options" in

Releasing an X.Y.N version

  • git checkout rel-X-Y-patches
  • update Inbox message with release notes
  • dists/Linux/ include SQL fixup scripts
  • git commit

  • git checkout master
  • git cherry-pick ...

  • git checkout rel-X-Y-patches
  • gnumed/client/ set client version X.Y.N
  • dists/Linux/ set proper client version X.Y.N
  • run at least minimal release tests:
    • database bootstrap (
    • database upgrade (
    • database fixup (
    • client startup (
      • patient activation
      • activate each tab once
      • new patient creation
  • fix bugs
  • git add
  • git add
  • git commit -v
  • git tag -s rel-X-Y-N
  • re-publish manual
  • build tarball
    • run dists/Linux/
  • upload to "Savannah"
  • adjust gnumed-versions.txt
  • update release status page
  • build packages for version X.Y.N
    • Debian package
    • Windows installer
    • Mandriva RPM
    • Suse RPM
    • Gentoo ebuild
    • MacOSX? DMG image
    • ... ?
  • incorporate feedback, fix bugs

During Release

Announce packages

mailing lists

portal sites


After Release

  • take a break
  • fix bugs in rel-X-Y-Z-patches
  • take another break
  • think about next Release


The GNUmed Versioning Scheme

Versions are defined by the corresponding tag in the CVS tree. The version string consists of 3 parts:

  • major version, currently 0
  • minor version, currently 5
  • patch level or release candidate

Features will only be introduced between minor-version changes. Patch level releases will never have new features, they will only ever receive bug fixes. Bug fixes are applied to CVS HEAD and to the latest release only so it is advised to stay up to date with released versions. Patch level releases will also never require a database change.

The tagging strategy is this (assuming 0.4):

The code gets ready for a release. Let's assume the release is to be v0.4.0. The CVS trunk (HEAD) is tagged as rel-0-4. This tag will become the root of a branch on which the actual 0.4.0 release will happen while HEAD can continue to evolve. A branch rel-0-4-patches is created and rooted at tag rel-0-4. This branch will only ever receive bug fixes. In that branch the tag rel-0-4-rc1 is set which will then be released as v0.4.rc1.

Bugs get fixed and eventually the branch is tagged as rel-0-4-0 which gets released as v0.4.0. More bugs get fixed and eventually the branch is tagged as rel-0-4-1 which then gets released as v0.4.1.

Eventually, CVS HEAD is tagged as rel-0-5, branched off into rel-0-5-patches and the cycle starts over.

The database schema is versioned independant of the client. At startup the client checks whether it was released to work with the database it connects to. For any necessary database upgrades we provide tested, integrity-checking conversion scripts.

A few historical -devel postings which predated the above include this one and another.
Topic revision: 05 Apr 2018, KarstenHilbert
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark