Preliminary tasks

Before you can start your build, you must make sure that the project is ready to be built.

1. Communicate

Starting this step means that the Development phase of this release is over (freeze step):

Verify that the release milestone on github is 100% complete. If there are still PRs remaining, create the milestone for an another release and tag the remaining PRs to it.

Inform the @prestashop/committers about the release tracking issue. If discussions arise regarding critical bugs, inform QA and the PM. They will be responsible for assessing the criticality of the bugs.

Inform the team in charge of Autoupgrade, and ask them if a version update is necessary (PRs with the tag “Needs Autoupgrade PR”).

Before you go further, make sure to tick the “Development” box in the Release Tracker GitHub issue (there is one per version, see the 1.7.6.6 example).

2. Create a branch for your build

The following tasks will require you to perform changes and submit them as a Pull Request.

example : If the release is 9.0.2, create a branch from 9.0.x and name it 9.0.2-build

• Clone the project on your computer using Git (only if you don’t already have a local copy of the repository).

  git clone [email protected]:PrestaShop/PrestaShop.git
  

• Make sure that you switch to the appropriate branch regarding the version you’ll be building

• Make sure your branch is up-to-date with upstream. Especially if you already had a local clone of the repository.

The next steps and PRs to be performed will be done on the build branch (freeze).

NB : For a minor or major version see additionnal steps on create version branch page.

3. Make sure the version number has been updated in the Core

Check the following files and update them if necessary:

• /install-dev/install_version.php:

  // update the version number below
  define('_PS_INSTALL_VERSION_', '1.7.6.2');
  

• /app/AppKernel.php:

  // Update the version number and version components (const *VERSION and the other one, which depends for patch or minor)
  const VERSION = '1.7.6.2';
  const MAJOR_VERSION_STRING = '1.7';
  const MAJOR_VERSION = 17;
  const MINOR_VERSION = 6;
  const RELEASE_VERSION = 2;
  

Make a pull request and have it merged.

Be careful: changing the version number impacts UI tests. To allow UI tests to run, you need to update the Distribution API to acknowledge the new version even though it does not exist yet. To do so, submit a PR similar to this example.

4. Make sure the default translation catalogue has been updated and pushed to Crowdin

1. Use the Github Action to extract wordings from the TranslationTool repository. This command will automatically generates a Pull Request on the PrestaShop/PrestaShop repository (author should be jarvis). It is important to note that this PR must be reviewed by a member of the content team. https://github.com/PrestaShopCorp/TranslationTool is PRIVATE, and then you need special access rights to use it.

2. Access the Crowdin interface and validate any new translations (they can be found either in the PrestaShop CORE, a module, or in the directory /mails of the PrestaShop CORE).

3. If the correction occurs in a module, a release must be made, along with a bump in the composer.json of the CORE, before re-extracting.

4. If the wording to be corrected is found in /mails/themes/modern, you should first correct it in https://github.com/PrestaShop/mjml-theme-converter and the mail templates in the PrestaShop CORE should also be regenerated (using https://github.com/PrestaShop/mjml-theme-converter ).

5. Once all the wordings have been corrected, validated and merged, a Github Action can be used on the TranslationTool repository to push the catalogs to Crowdin (the repository need right access).

5. Lock the theme version

The theme has been moved outside of the Core repository since version 8.0.0.

• Create a git tag on the Theme repository

This tag is needed to lock the theme version when a new release is built.

• Tag the new version:

  git tag 2.0.0-rc1 # replace with your version
  

• Push the tag:

  git push 2.0.0-rc1 # replace with your version
  

• Update composer.lock to target the new tag

6. Release any necessary improvement on the Update Assistant module

Some releases need an update of the Update Assistant module, and some do not. For example, if the MySQL database schema has been updated between two versions of PrestaShop, a schema update SQL script is needed, and it has to be added to the list.

Please verify whether or not this new version of PrestaShop requires

• to modify the source code of the Update Assistant (autoupgrade) module
• to publish a new version (using the up-to-date content of the source code) of the Update Assistant (autoupgrade) module

If yes, please follow the release process of the Update Assistant module.

7. Manual verifications

Make sure that in the current branch:

• All license headers are correct:

  php bin/console prestashop:licenses:update
  

• All controllers are secured by annotations, and legacy link are provided for Symfony routes (starting from 9.0.x this step is obsolete as it is checked in the CI already):

  php bin/console prestashop:linter:security-annotation find-missing
  php bin/console prestashop:linter:legacy-link
  

• All versions of the composer packages correspond to a release tag and not a development branch tag.

  "prestashop/ps_apiresources": "dev-dev", // incorrect tag
  

• There are no known vulnerabilities in composer dependencies using composer audit to check vulnerabilities.

• (Minor and major releases only) – No important @todo annotations have been left forgotten in new code

• All new hooks have been registered

• The generated FOS JSON routing file is up-to-date:

  php bin/console fos:js-routing:dump \
      --format=json \
      --target=admin-dev/themes/new-theme/js/fos_js_routes.json
  

• Any new native modules have been added into composer.json and their latest versions have been updated in composer.lock:

  composer outdated -D "prestashop/*"
  

• Nightly builds are green

8. Create the new version in the PrestaShop Marketplace and update native module compatibility

The preliminary steps are completed, you can now proceed to the build steps.