Release Management

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

Before Release

Development (CVS HEAD)

• fix feature set in Roadmap
• complete features in CVS
• fix bugs reported in the bug tracker
• complete database schema changes
• update list of current features
• update User Manual
• update manual publisher topic
• initial round of testing for release fitness

Preparing .rcN release candidates (CVS HEAD)

• pycommon/gmPG2.py:
  • add hash of new database
  • teach it which database version to expect for the new client branch
• make-release_tarball.sh: include SQL upgrade scripts
• upgrade-vN_vN+1.conf: expect new database version instead of devel
• bootstrap-latest.conf: include latest upgrade-vN_vN+1.conf
• bootstrap-latest.sh: include latest database release
• net_upgrade-gnumed_server.sh: refer to the latest database version
• client/doc/make-*.sh scripts: refer to the proper databases
• grep the tree for instances of the old database name and replace with the new one where appropriate

• wash/rinse/repeat the following as needed:
  • temporarily edit make-release_tarball.sh to have the proper database version and client version X.Y.rcN
  • temporarily edit wxpython/gnumed.py to know about client version X.Y.rcN
  • tag CVS tree as rel-X-Y-rcN
    • run cvs tag -c rel-X-Y-rcN
    • means: Release Candidate N for version X.Y.0
  • test basic functionality (startup !)
  • publish Release Candidate in our download area
  • adjust gm-versions.txt
  • upgrade public database
  • incorporate feedback, fix bugs
  • download and merge any new translations from Launchpad

Preparing the .0 release (CVS HEAD)

• tag CVS tree as "rel-X-Y"
  1. sync (update/commit) working copy with HEAD branch
  2. run cvs tag -c rel-X-Y
• create branch rel-X-Y-patches off of tag rel-X-Y
  • run cvs rtag -b -r rel-X-Y rel-X-Y-patches gnumed in a working copy of the HEAD branch
  • the branch rel-X-Y-patches will receive bug fixes only for version X.Y.
• check out rel-X-Y-patches as a new working copy

Further preparing the .0 release (rel-X-Y-patches)

• edit make-release_tarball.sh to use the new database version

• update installation instructions

Releasing a .N version (rel-X-Y-patches)

• wash/rinse/repeat as needed:
  • edit dists/Linux/make-release_tarball.sh to have the proper client version X.Y.N
  • include SQL fixup scripts in make-release_tarball.sh
  • edit client/wxpython/gnumed.py to know about client version X.Y.N
  • sync (update/commit) the branch rel-X-Y-patches
    • run update_tree.sh
  • test (startup !)
  • tag CVS tree in rel-X-Y-patches as rel-X-Y-N
    • run cvs tag -c rel-X-Y-N
  • build tarball
    • run dists/Linux/make-release_tarball.sh
  • 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

• gnumed-devel and gnumed-update
• Debian Med Packaging Team: debian-med-packaging @ REMOVETHIS lists.alioth.debian.org
• resmed-de
• python-announce (comp.lang.python)
• postgresql-announce
• http://lists.debian.org/debian-med/
• tm-anwender
• OpenHealth lists: old/new
• wxPython
• ... ?

portal sites

• http://gnumed.blogspot.com
• http://www.gnumed.org
• http://www.gnumed.de
• gnumed Wiki
• http://www.linuxmednews.com
• http://freshmeat.net
• http://sourceforge.net
• http://www.facharzt.de
• EDV-Forum Ärzteblatt
• PraxisComputer-Magazin (E-Mail Heike Krüger-Brand)
• http://forum.gnumed.de (Von Doc zu Doc)
• Linux 4 Clinics
• ... ?

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.