Release Guide

  • content: documents steps for releasing a new Phile version
  • audience: core-developers

Prepare Code

Create release branch

  • branch release/<version-string> release-branch from "develop"

Update version-strings

  • update version string in config/bootstrap.php
  • update

Update Composer

  • update version string in composer.json

Without the version string composer will not pickup Phile's version number. It assumes "1.0.0" and will throw an error if you want to install Phile-plugins requiring "Phile >1.0.0".

  • run composer update --lock

Just generate new hash in the .lock file without updating packages. Avoids "composer.lock outdated" message.

Process Deprecated

  • check code for @deprecated and whether they are due for removal: open a todo-issue for the next release (or remove if trivial)
  • check new @deprecated that proper "since <version-string>" is set
  • update release-note with those changes

Check that everything is still O.K.

  • run-test cases
  • check CI services are "green"
  • create release package (see below) and do a test install

As you see fit:

  • announce release branch for (public) testing
  • publish pre-release for (public) testing

Release Code

Make Release

  • merge the "release" branch into "master"
  • last check that everything is still "green"
  • tag "master" with version-string and push to origin

Pushing the tag to the public github repository marks the official release. The tag or code of that release must not be changed. Instead a new release must be published.

Create Release Package

  • create release package

Use the phing build system (./phing) to create the release package.

  • attach release .zip to github release-page

Publish Release Notes

  • publish release-note on release-tag


  • merge "master" into "develop"
  • remove "release" branch
  • (if exists) close the milestone in the issue tracker


  • create a new boilerplate "next" release-page

Update Homepage

See instructions at

Edit the source page on github…