Stages in the release process

Open Development

Here we update version numbers in 'trunk' of source code and any documentation etc stored in subversion (SVN). SVN is the system we use for managing our code.

Help needed: none at this stage (theres not really much work for us)

Feature freeze

The only thing we do here really is make an announcement. The purpose of feature freeze is to have a period of stabilisation before a release. No new features can be worked on. Only work allowed is polishing existing features and fixing bugs. Sometimes
we make exceptions but we try not to.

Help needed: none at this stage (theres not really much work for us)

String freeze and call for translations

First we update the translation files, and update the change logs and whats new? lists etc. Then we make a 'call for translations' announcement. During this period bug fixes can continue but changes to translatable strings in the source should be avoided. At the end of the string freeze cycle we call on translators to submit their work prior to branching.

Help needed: It would be great to have some help writing more complete feature lists. This will require examining the change logs and perhaps asking the authors of various features what they have done that is new / better / fixed etc.

Branching and call for packaging

We create a 'branch' in SVN that contains all the code that will be part of the release. Once the branch is created, open development can continue again in trunk of SVN. The only code changes that can be made in the release branch should be changes needed for packaging (installers for different operating systems).

Help needed: None at this stage (theres not really much work for us)


We freeze any further changes to the branch and make it read only. It becomes a snapshot in time of a particular point in the development of QGIS. Packages are uploaded to

Help needed: At the moment not so much needed here - this may change

Release publicity

This is the part where I really want help! There are a host of things that need to be done including:

  • create templated press releases (would be great to have them in multilanguages!)
  • post announcements to various websites - the release checklist has an initial list but they are 99% english language ones - it would be great to target the websites of your country too
  • create an announcement wiki page, with a description of the program, the catchiest features, some screenshots and interviews to developers. Follow the template ReleaseAnnouncementTemplate
  • post to qgis blog, update the qgis website (all references to old version need to be replaced with new version)
  • post to mailing lists
  • for bigger releases we can target other media such as gis podcasts etc
  • deal with issues relating to the release (packages not working, broken links etc etc)

Help needed: Spreading the above tasks amongst the release team and documenting what we do.

Release checklists

Everything in the above steps fairly well documented in the QGIS ReleaseChecklistTemplate which is used to generate the
checklist for each release (see ReleaseChecklists). I say 'fairly well because before I started the release process was
undocumented and I'm still getting the templates perfected in terms of sequencing and completeness.