Release the version publicly

Once the QA team has greenlighted your build, you can move forward with the public release.

Make certain you have go for publish! Also, avoid starting this process after 4 PM or on a Friday.

1. Merge security PRs on GitHub

If there are unmerged security PRs:

  • Merge them on GitHub and publishing their security advisories.
  • Rebase the local build branch that you created on the previous step to remove the merge commits from the security PRs you merged manually before.

2. Merge the updated changelog and contributors list

Starting from your local build branch:

  • Double check your branch and verify it contains only the updated contributors list and the new changelog.
    The commit named // Changelog [version] should be the last one.
  • Create a Pull Request to merge this change.

3. Tag & release on GitHub

Tag the version using git

You can do this step using Git or directly on GitHub on the next step.
  • Check out the commit named // Changelog [version]
  • Tag the new version: 
    git tag 1.7.2.0 # replace by your version
git push --tags

Publish the release on GitHub

Create a new Release Draft on GitHub

  • Either:

    • Pick the tag that you created in the previous step
    • Create the tag by picking the Changelog commit that you just merged.
      ⚠️ Make sure you pick the Changelog commit itself, not the PR’s merge commit!

  • Paste the change log as a description

    • If you’re publishing a version (including beta and RC releases) that includes changes from a previous pre-release version:

      • Include a note explaining what other changes are included (Example)
      • Precede the changelog with the title “Changes since beta XX / RC YY…" (Example)

    • If you’re publishing a pre-release version:

      • Make sure to add a “Known issues” section (Example)
      • Don’t forget to check the “This a pre-release” checkbox at the bottom of the form

    • If you’re publishing a patch version:

      • Write a short intro explaining what the release fixes – especially if it’s a security release! (Example)

  • Upload the new version zip archive (the one that has been validated by QA).
    Remove the build number from the file name to avoid confusions.

If the Changelog content is too long

It’s not unusual to have very long changelogs, especially in minor versions. To reduce its size, we recommend putting it in a collapsable paragraph:

# Full Changelog
 
<details><summary>Click here to see</summary>
<p>
- Back Office:
  - New feature:
    - #xxxxx .....
...
</p>
</details>

4. Release on prestashop.com

This step requires special rights.

Ask a maintainer from the PrestaShop Company with admin access to prestashop.com to perform this step.

5. Communicate

Congratulations! You can now update the Release Tracker GitHub issue: tick the “QA” and “Development” boxes and add a comment.