DokuWiki

It's better when it's simple

User Tools

Site Tools


Sidebar

Translations of this page?:

Learn about DokuWiki

Advanced Use

Corporate Use

Our Community


Follow us on Facebook, Twitter and other social networks.

Our Privacy Policy

devel:release_process

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.

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

  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. 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

Release

  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 dokuwiki.org 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 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=`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
1)
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: 2018-04-21 08:08 by andi