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 1.7.2.0 # replace by your version
git push --tags
Create a new Release Draft on GitHub
Either:
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.