Create a build package

Once preliminary tasks have been completed, the project is ready to be built.

1. Communicate

Starting this step means that the Development phase of this release is over.

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 local branch for your build

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

• 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 (e.g. you must be on branch 1.7.7.x if you’re building a 1.7.7 release).

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

• Create a local branch for your work. Keep it! You will need to go back to it later.

3. Merge any not-yet merged security fixes into your branch

To avoid disclosing security issues before the version is released, security Pull Request are merged in GitHub after the build has been validated. In order to include them in your build, you need to retrieve them manually and merge them in your local branch.

If this release includes security PRs:

• Add the different private temporary repositories for each Security Advisory as remotes of your local git repository.
• Merge each one of those PRs into your working local branch.

4. Update the Changelog & Contributors list

Extract list of changes and contributors using the changelog tool

After this step, you should obtain two files:

• the Changelog file – including a list of all the merged Pull Requests. Make sure to keep this file, you’ll need it later.
• the New Contributors file – a list of all the people who contributed code for this version for their first time.

Update the project’s files

• Add the contents of the changelog at the top of PrestaShop’s Changelog file.
• Update PrestaShop’s Contributors file by adding the new contributors. Keep the alphabetical order.
• Commit your changed files with following message: “// Changelog [version]”

5. Push your work into a build branch

The build branch helps other people verify your work, and allows the base branch to continue receiving merges while your build is being validated.

If your build is rejected because of a bug, the fixes will have to be merged into your build branch, instead of the base branch.

If the branch does not contain security fixes

• Push your changes to a new branch in the public repository.
  Name your branch following this scheme: [version]-build (for example: “1.7.8.1-build”)
• Create a new pull request to merge your changes. If you’re lost, see this example from the 1.7.6.6 release.

If the branch contains security fixes

• Push your local branch into a private repository, in order to avoid disclosing the security bugs.
• Share access to your private repository with other maintainers so that they can verify your work.

6. Build the ZIP archive

Use the Release Creator CLI script included with PrestaShop’s sources to create the ZIP archive.

From the root path of your repository, execute:

php tools/build/CreateRelease.php --version="1.7.6.6"

This tool creates a build based on the state of your workspace using git archive. Therefore, files not tracked by git won’t be included in the build.

Make sure you’re building from the branch you updated in the previous step. Otherwise the package won’t include the updated changelog and contributors files.

By default, the release package will create two files in a new subdirectory in /tools/build/releases:

• A ZIP package, containing the software.
• An XML file, containing md5 checksums for every file within the package.

As an optional step, consider downloading the latest stable release package and compare the contents of the zip archives to look for suspicious changes.

7. Archive your build

Rename files

Rename both files according to our naming convention:

prestashop_<version>-[beta.<beta number>|rc.<rc number>]+build.<build number>.<zip|xml>

Upload files to the archive

8. Communicate and wait for QA validation

At this point, the build process is over.

• Make sure the build files have been submitted to the QA team.
• Update the Release Tracker GitHub issue. Tick the “Build” box, and add a comment to announce that the build has been submitted to QA (see example).
• Wait for QA to validate the build.

If the QA rejects the build

In case the QA team finds blocking defects in the build, then these issues must be fixed and merged before the branch can be built again.

• Communicate that the build validation has failed by updating the Release Tracker GitHub issue.
• Fix the issues or wait for them to be fixed and merged in the build branch you created above (and NOT in the base branch!).
• Repeat the build process from the top. Make sure that you have checked out the head of the updated version branch.

Once the QA has greenlighted the build, you can move on to publishing the version.