It's better when it's simple

User Tools

Site Tools


Release process

Release cycle

We lack the man power to manage a strict release cycle. We usually release about once a year with hotfixes when important security patches are needed.


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.

FIXME: many tasks below have been automated by the GitHub release workflows. Needs to be refactored.

Version Naming Conventions

  • Release Candidates use the date on which they are released, prefixed with rc
    • rc2022-06-26 “Igor”
    • rc2022-07-01 “Igor”
  • Releases use the date on which they are released, no prefixes or postfixes
    • 2022-08-12 “Igor”
  • Hotfixes add a letter to the date of the release they fix
    • 2022-08-12a “Igor”
    • 2022-08-12b “Igor”


  1. find a code name
    • Discworld Character starting with a letter alphabetically after the first letter of the last release name
  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. increase the update_check msg number in doku.php
  3. update list of deleted files
    • git diff stable..HEAD --summary | awk '/^ delete/ && $4 !~ /^(VERSION|_test|_cs)/ {print $4}'
    • add them to data/deleted.files
  4. push the release preparations above to the master branch
  5. merge git master branch into the stable branch
    • git merge -Xtheirs master helps with conflicts
  6. 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''
  7. tag the release in the git stable branch
    • ''git tag 'release_stable_YYYY-MM-DD' '' or
    • ''git tag 'release_candidate_YYYY-MM-DD' '' or
  8. 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) 1)
  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: 2023-09-24 20:46 by andi

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki