This is an old revision of the document!
Table of Contents
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 dokuwiki.org :)
- If Release:
- release team: Create tarball
- marketing team: Update profiles
Security
We provide security fixes for the two most recent versions.
Deprecation
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.
Releasing
The following steps have to be taken for building a new release.
Preparation
- find a code name
- add RC1(-9) for release candidate
- check https://github.com/splitbrain/dokuwiki/issues for new bugs
- prepare changes summary
- update release name and changes summary on releases
- run unit tests (and check http://test.dokuwiki.org/master.html)
Code changes
- push the current
stable
branch to theold-stable
branch (only once per release cycle)git checkout old-stable git merge -X theirs stable
- make sure the MD5 for
conf/dokuwiki.php
in the installer is correct; this includes- checking the MD5 value
- checking whether the installer fails
- increase the update_check msg number in
doku.php
- update list of deleted files
git diff stable..HEAD --summary |grep '^ delete'|awk '{print $4}'|grep -vE '^(VERSION|_test|_cs)'
- add them to
data/deleted.files
- push the release preparations above to the
master
branch - merge git
master
branch into thestable
branchgit merge -Xtheirs master
helps with conflicts
- 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''
- tag the release in the git
stable
branch- ''git tag 'release_stable_YYYY-MM-DD' '' or
- ''git tag 'release_candidate_YYYY-MM-DD' '' or
- push the
stable
branch to gitgub:git push --tags origin stable
Create release
- build the .tgz (See build script below)
- test-install the tarball
- test-upgrade from previous stable using the tarball
Release
- push git
- upload the .tgz (needs to be done by Andi, Adrian or Guy currently)
- update release numbers in bugtracker (needs to be done by Andi, Adrian or Guy currently) 3)
- change message in IRC (needs to be done by Andi, Adrian, Guy or Hakan currently)
- Update release list in dokuwiki.org config of the pluginrepo plugin
- announce in fm (needs to be done by Andi currently)
- announce in wikimatrix (needs to be done by Andi or Adrian currently)
- announce in mailing list, forum, weping
- update update.dokuwiki.org (needs to be done by Andi, Adrian or Guy currently)
Tarball build script
- build.sh
#!/bin/sh set -e BDIR=/home/andi/projects/buildplace cd $BDIR rm -rf dokuwiki* git clone git://github.com/splitbrain/dokuwiki.git dokuwiki cd dokuwiki 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 .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
- 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
- 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”)
- Update VERSION file (append letter to date, starting with “a”) in stable and old-stable, commit named like the release.
- tag the release in the git
stable
andold-stable
branches - build new tarball of
stable
andold-stable