How to release a new PrestaShop version

This section describes the release process, step by step. A PrestaShop version release requires all these steps to be completed.

Prerequisites

To perform a build, you will need the following:

• Git, so you can clone the project’s Git repository on your computer.
• The PHP CLI executable (within the compatible version range of the PrestaShop version you will be building), so you can create a build.
• The Composer executable, to fetch PHP dependencies.
• The NodeJs CLI executable (within the compatible version range) and NPM, to compile assets.

Different types of releases

We currently have 4 kind of new releases for PrestaShop:

• security patch releases
• regular patch releases
• minor releases
• major releases

Security patch releases contain security fixes for major security issues. Please read about them.

Process overview

1. Perform preliminary tasks: (click to see the full step)

   Short summary:

   • Set up the new version on the PrestaShop Addons Marketplace and update native modules' compatibility.
     To allow the PrestaShop Addons Marketplace and its API to serve modules compatible with this new PrestaShop version.

   • Update the version number in the Core.

   • Make sure the default translation catalogue has been updated and pushed to Crowdin.
     To make any new wordings translatable.

   • Lock the theme version.

   • Make sure to trigger the release of the Upgrade module if necessary.

   • Perform manual verifications.
     To make sure that the project is ready to be built.

2. Create a new build: (click to see the full step)

   Short summary:

   • Merge security PRs locally.
     Any security PRs must be merged on a local branch before making them public.

   • Update the Changelog and Contributors list.
     These files must be included in the build.

   • Push your work into a build branch.
     Allows the base branch to continue receiving merges while your build is being validated.

   • Build and store the zip archive.
     The ZIP archive contains the software (including third party dependencies) and compiled assets (Javascript and CSS), but not the development sources, dev dependencies & tests.

   • Deliver to QA team.

3. Release the version publicly: (click to see the full step)

   Short summary:

   • Merge security PRs on GitHub.
     And publish the security advisories.

   • Merge the updated Changelog and Contributors list on GitHub.

   • Tag the version using Git and publish the release on GitHub.

   • Communicate.

4. Final steps: (click to see the full step)

   Short summary:

   • Update API stream for 1-click upgrade.
     So that the 1-Click Upgrade (autoupgrade) module becomes aware of the new release.

   • Create Docker images for the new version.

   • Go through the checklist.
     To make sure everything went all right.

   • Store the ZIP archive.
     To keep track of all published versions.

   • Improve the process.