Isaac Bennetch edited this page Apr 24, 2018 · 8 revisions
Clone this wiki locally

This is a short documentation on creating a release of phpMyAdmin. The file '' also prints instructions.

  1. Adjust ChangeLog in the target branch - at least release date has to be set, if performing a security release then make sure security issues are noted in the ChangeLog as well. Set the proper version in the appropriate files (noted by the script).
  2. Checkout the phpmyadmin repository, master branch (even if you intend to release from another branch).
  3. Run ./scripts/, for example: ./scripts/ 3.3.0 MAINT_3_3_0 --tag --stable
  4. Follow instructions printed by the script, most importantly
    • Write release notes
    • Upload the files to the file server
    • Add news item and send announcement mails
    • Increase version in released branch (usually gets a -dev suffix so that the error-reporting server knows the difference between a released version and a development version).

Stable releases

For stable releases, we maintain separate STABLE branch in Git, which users can follow. This one is updated by passing --stable to the create release script:

./scripts/ 4.5.4 MAINT_4_5_4 --tag --stable

Only most up to date stable branch should be marked as stable.

Security release

If doing security release, you need to first merge embargoed security branch into release one:

git checkout MAINT_4_4_15 git merge MAINT_4_4_15-security

Then you can follow the usual release instructions:

git checkout master ./scripts/ MAINT_4_4_15 --tag

Docker tags for security releases should follow the x.y.z-1 pattern, not x.y.z.1-1. Docker seems to not recognize the latter format.

Removing stale maintenance branches

Once maintenance for given branch is over, it can be removed from git. For example once 4.5.4 is released, maintenance branch for 4.5.3 can be removed as it won't receive further updates:

git push origin :MAINT_4_5_3

Pre-release versions

When creating a pre-release version, such as -alpha1 or -rc2, we create a Git tag but of course don't move up STABLE. Typically, we create the QA_ branch before the release of -beta1, to reduce the inclusion of new, untested features.