Release process

We run a time-based release cycle with two releases every year. The first release takes place in April, the second in October.

• Early March / September: Feature Freeze (Decision by release team together with devel team)
  • 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 (might be done by quality team): Run unit tests, 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 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 (might be done by quality team): Run unit tests, 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: install RC on dokuwiki.org :)
  • 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
   • add RC1(-9) for release candidate
2. check https://bugs.dokuwiki.org for new bugs
3. prepare changes summary
4. update release name and changes summary on releases
5. run unit tests

1. push the current stable branch to the oldstable branch (only once per release cycle)
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 |grep  '^ delete'|awk '{print $4}'|grep -v VERSION

   • add them to data/deleted.files
   • add them to upgrade
5. push the release preparations above to the master branch
6. merge git master branch into the stable branch
7. update the VERSION file in the stable branch
   • Format: ''YYYY-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

1. build the .tgz (See build script below)
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 or Adrian currently)
3. update release numbers in bugtracker (needs to be done by Andi, Adrian or Guy currently)
4. change message in IRC (needs to be done by Andi, Adrian or Hakan currently)
5. announce in fm (needs to be done by Andi currently)
6. announce in wikimatrix (needs to be done by Andi or Adrian currently)
7. announce in mailing list, forum, weping
8. update update.dokuwiki.org (needs to be done by Andi, Adrian or Guy currently)
9. Update release list in https://github.com/splitbrain/dokuwiki-plugin-pluginrepo (either upstream or dokuwiki.org config)

build.sh

#!/bin/sh
 
BDIR=/home/andi/projects/buildplace
 
cd $BDIR || exit
rm -rf dokuwiki*
 
git clone git://github.com/splitbrain/dokuwiki.git dokuwiki
cd dokuwiki || exit
git checkout -b stable origin/stable
 
VERSION=`cat VERSION|awk '{print $1}'`
 
rm -rf .gitignore
rm -rf .git
rm -rf _test
rm -rf _cs
rm -f test.php
mkdir 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"

1. increase msg number in master (“release preparation”)
2. cherry pick bugfix commit in stable and old-stable
3. cherry pick “release preparation” commit in stable
4. Update VERSION file (append letter to date, starting with “a”) in stable and old-stable, commit named like the release.
5. tag the release in the git stable and old-stable branch
6. build new tarball of stable