Release Management

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

Before Release

Development (VCS HEAD)

• fix feature set in Roadmap
• complete features in VCS (e.g. GIT)
• fix bugs reported in the bug tracker
• complete database schema changes
• update User Manual
• update manual publisher topic
• initial round of testing for release fitness

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/gmPG2.py:
  • 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
• make-release_tarball.sh: 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
• bootstrap-latest.sh/.bat: 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
• make-release_tarball.sh: set proper database version and client version X.Y.rcN
• wxpython/gnumed.py: 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

• incorporate feedback, fix bugs

Preparing the X.Y.0 release

• git checkout master

• gm-net_upgrade_server.sh: refer to the latest database version
• bootstrap-latest.sh/.bat: include latest database release
• bootstrap-latest.conf: include latest upgrade-vN_vN+1.conf

• 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

• update list of current features
• update installation instructions

Releasing an X.Y.N version

• git checkout rel-X-Y-patches

(wash/rinse/repeat as needed)

• update Inbox message with release notes
• gnumed/client/gnumed.py: set client version X.Y.N
• git add gnumed.py
• dists/Linux/make-release_tarball.sh: set proper client version X.Y.N
• dists/Linux/make-release_tarball.sh: include SQL fixup scripts (also in branch master)
• git add make-release_tarball.sh
• run at least minimal release tests:
  • database bootstrap (bootstrap-latest.sh)
  • database upgrade (upgrade-db.sh)
  • database fixup (fixup-db.sh)
  • client startup (gm-from-vcs.sh)
    • patient activation
    • activate each tab once
    • new patient creation
• git commit -v
• git tag -s rel-X-Y-N
• re-publish manual
• 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
• Version Tracker - Mac OS X
• ... ?

other

• email Kelly Hopkins via RT <bug-directory@gnu.org> asking to change version data on
  • http://directory.fsf.org/project/gnumed/

After Release

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

---

#GNUmedVersionNumbers

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.