Table of Contents
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
changelog.md
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
@deprecatedand whether they are due for removal: open a todo-issue for the next release (or remove if trivial) - check new
@deprecatedthat 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
Cleanup
- merge "master" into "develop"
- remove "release" branch
- (if exists) close the milestone in the issue tracker
Optional:
- create a new boilerplate "next" release-page
Update Homepage
See instructions at https://github.com/PhileCMS/PhileCMS.github.io