Notice: You are browsing the documentation for PrestaShop 8, which is currently in development.You might want to read the documentation for the current version, PrestaShop 1.7.
Once the QA team has greenlighted your build, you can move forward with the public release.
If there are unmerged security PRs:
Starting from your local build branch:
// Changelog [version]should be the last one.
// Changelog [version]
git tag 220.127.116.11 # replace by your version git push 18.104.22.168 # replace by your version # Alternatively (mainly to solve tag/branch name clashes), you could use git push origin refs/tags/22.214.171.124
Create a new Release Draft on GitHub
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:
If you’re publishing a pre-release version:
If you’re publishing a patch version:
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.
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>
This step requires special rights.
Ask a maintainer from the PrestaShop Company with admin access to prestashop.com to perform this step.
Congratulations! You can now update the Release Tracker GitHub issue: tick the “QA” and “Development” boxes and add a comment.