Home

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/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

  • 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-maint rel-X-Y (create a branch from that tag)

  • git checkout rel-X-Y-maint

  • git merge rc-X-Y

  • git branch -d rc-X-Y

  • activate "tarball release options" in gm-from-vcs.sh

  • update list of current features

  • update installation instructions

Releasing an X.Y.N version

  • git checkout rel-X-Y-maint

(wash/rinse/repeat as needed)

  • update Inbox message with release notes

  • run database release tests:

    • database bootstrap (bootstrap-latest.sh)

    • database upgrade (upgrade-db.sh)

    • database fixup (fixup-db.sh)

  • gnumed/client/gnumed.py: set client version X.Y.N

  • run client release tests:

    • client startup (gm-from-vcs.sh)

      • from the console

      • without a console (invoke gm-from-vcs.sh from, say, dolphin)

      • patient activation

      • activate each tab once

      • new patient creation

      • again, activate each tab once

  • 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)

  • test building tarball

    • run dists/Linux/make-release_tarball.sh

  • git add gnumed.py

  • git add make-release_tarball.sh

  • git commit -v (suggested message "Prepare X.Y.N release")

  • git tag -s rel-X-Y-N (suggested message "Stamp X.Y.N release")

  • 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

portal sites

other

After Release

  • take a break

  • fix bugs in rel-X-Y-Z-maint

  • 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-maint 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-maint and the cycle starts over.

The database schema is versioned independent 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.