DokuWiki

It's better when it's simple

User Tools

Site Tools


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.

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”

Preparation

  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

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