It's better when it's simple

User Tools

Site Tools


Translations of this page?:

Learn about DokuWiki

Advanced Use

Corporate Use

Our Community

Follow us on Facebook, Twitter and other social networks.


Release process

Release cycle

We run a time-based release cycle with two releases every year. The releases are done after a fixed schedule feature freeze giving necessary time to fix bugs. Thus releases will be spring and autumn.

  • 1st February / 1st August: Feature Freeze (Triggered by automated mail)
    • release team: Create tickets for removing outdated deprecations
    • release team (might be done by Bug/Wishlist Review Team): Collect todo tickets for release
    • release team: Create changelog
    • release team and quality team: Run unit tests1), coding standard checks, check HTML
    • i18n team: Update Translation (Assume stable string set from now on)
    • documentation team: Update documentation (Assume stable from now on)
    • plugin & template team: Write plugin / template developer infos (what got deprecated, what was removed, what is new)
  • Release / RC (Transition to this step as soon as all todo tickets are closed, ca 1 week after last transition at minimum)
    • If RC:
      • release team: Manage new tickets (Mark as todo)
      • release team: test upgrade last stable installation, Inform / update derivatives
      • release team and quality team: Run unit tests2), coding standard checks, check HTML
      • i18n team: Take a look at bad translations, exclude them? (Here?)
      • release team: inform plugin & template team, documentation team, i18n team on changes relevant to them
      • andi or Guy: install RC on :)
    • If Release:
      • release team: Create tarball
      • marketing team: Update profiles


We provide security fixes for the two most recent versions.


Removing legacy interfaces, behaviours and features is done over a period of three releases: In the first release, the object is deprecated, in the third, removed. This means that a plugin or template which only uses non-deprecated aspects should at least work in two future versions as well. Put the other way: A template or plugin older than a year is possibly broken.


The following steps have to be taken for building a new release.


  1. find a code name
    • Discworld Character starting with a letter alphabetically after the first letter of the last release name
    • add RC1(-9) for release candidate
  2. prepare changes summary
  3. update release name and changes summary on releases

Code changes

  1. push the current stable branch to the old-stable branch (only once per release cycle)
    git checkout old-stable
    git merge -X theirs stable
  2. make sure the MD5 for conf/dokuwiki.php in the installer is correct; this includes
    1. checking the MD5 value
    2. checking whether the installer fails
  3. increase the update_check msg number in doku.php
  4. update list of deleted files
    • git diff stable..HEAD --summary | awk '/^ delete/ && $4 !~ /^(VERSION|_test|_cs)/ {print $4}'
    • add them to data/deleted.files
  5. push the release preparations above to the master branch
  6. merge git master branch into the stable branch
    • git merge -Xtheirs master helps with conflicts
  7. update the VERSION file in the stable branch
    • Format: ''YYYY-MM-DD "code name"'' or ''rcYYYY-MM-DD "code name"''
    • commit: ''git commit -m "Release `cat VERSION`" -a''
  8. tag the release in the git stable branch
    • ''git tag 'release_stable_YYYY-MM-DD' '' or
    • ''git tag 'release_candidate_YYYY-MM-DD' '' or
  9. push the stable branch to gitgub:
    • git push --tags origin stable

Create release

  1. build the .tgz
    git checkout stable
    V=`awk '{print $1}' VERSION`; git archive -v --format=tgz --prefix="dokuwiki-$V/" --output="../dokuwiki-$V.tgz" HEAD
  2. test-install the tarball
  3. test-upgrade from previous stable using the tarball


  1. push git
  2. upload the .tgz (needs to be done by Andi, Adrian or Guy currently)
  3. update release numbers in bugtracker (needs to be done by Andi, Adrian or Guy currently) 3)
  4. change message in IRC (needs to be done by Andi, Adrian, Guy or Hakan currently)
  5. Update release list in config of the pluginrepo plugin
  6. announce in fm (needs to be done by Andi currently)
  7. announce in wikimatrix (needs to be done by Andi or Adrian currently)
  8. announce in mailing list, forum, weping
  9. update (needs to be done by Andi, Adrian or Guy currently)

Tarball build script
set -e
cd $BDIR
rm -rf dokuwiki*
git clone git:// dokuwiki
cd dokuwiki
git checkout -b stable origin/stable
VERSION=`awk '{print $100}' VERSION`
rm -rf .gitignore
rm -rf .git
rm -rf _test
rm -rf _cs
rm -f .editorconfig
rm -f .travis.yml
rm -f test.php
mkdir -p data/pages/playground
echo "====== PlayGround ======" > data/pages/playground/playground.txt
cd ..
mv dokuwiki dokuwiki-$VERSION
tar -czvf dokuwiki-$VERSION.tgz dokuwiki-$VERSION
echo "now upload: $BDIR/dokuwiki-$VERSION.tgz"

Building a Hotfix Release

  1. Make sure bugfix commit is in master, stable and old-stable
    • If there is a suitable commit in master, cherry-pick it into stable and old-stable
    • Else, write your own commit for stable and cherry-pick it into old-stable if suitable
    • Else, write another commit for old-stable
  2. Make sure the msg numbers are correct
    • Increase msg number in master by 0.1 (“Release preparations”)
    • Cherry-pick “Release preparations” commit into stable
    • Increase msg number in old-stable by 0.1 (“Release preparations”)
  3. Update VERSION file (append letter to date, starting with “a”) in stable and old-stable, commit named like the release.
  4. tag the release in the git stable and old-stable branches
  5. build new tarball of stable and old-stable
i.e. for RCs: add a “Reported Version” and don't remove any “Due in Version”, add a new “Due in Version” for the release after next; for standard releases: change the latest RC to non-RC “Reported Version”, remove current “Due in Version”
devel/release_process.txt · Last modified: 2017-09-02 09:04 by