Releasing

This is a short documentation on creating a release of phpMyAdmin. The file 'create_release.sh' 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/create-release.sh, for example: ./scripts/create-release.sh 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/create-release.sh 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/create-release.sh 4.4.15.3 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.

Docker

To release a new Docker image in our own repository, for each type (apache, fpm-alpine, fpm) edit the Dockerfile to change ENV VERSION. Create the tagged release with git tag -a 5.0.0 -m "5.0.0" and don't forget to push origin --tags.

For the official Docker Hub build, the workflow is a little more complex and requires submitting a pull request to their repository.

Category:Devel