What does it mean, “to release a new version of “PrestaShop”? Actually many different answers are eligible.
You could say that “a new version of PrestaShop is released when there is a new release on the GitHub repository”. Or you could say “a new version of PrestaShop is released when I can download a new version on prestashop.com”. You could also say “a new version of PrestaShop is released when the auto-upgrade module allows to upgrade to this new version”.
So let’s first put some words on all of these statements, to avoid any confusion.
Please check that:
php bin/console prestashop:licenses:update
php bin/console prestashop:linter:security-annotation
php bin/console prestashop:linter:legacy-link
@todoannotations in modern code
php bin/console fos:js-routing:dump --format=json --target=admin-dev/themes/new-theme/js/fos_js_routes.json
composer outdated -D "prestashop/*"
First you can update the Release Tracker GitHub issue (there is one per version, see the 18.104.22.168 example): step “Development” is done.
Before starting the making of the build, some files must be prepared by a member of PrestaShop company.
The Translations catalog must also be updated.
Here is the process to create a new version of PrestaShop 1.7.6 from its branch
1.7.6.x. Building a new version for other
1.7.x.y branches is very similar, same steps can be followed.
Clone the repository, checkout the branch
git clone firstname.lastname@example.org:PrestaShop/PrestaShop.git
Update the code to acknowledge the new version:
Create a new branch, commit your changed files with the message “// Changelog [version]”.
Example of Release Creator usage:
php tools/build/CreateRelease.php --version="22.214.171.124"
This allows you to create a new ZIP archive which contains the software. It can be installed and run, however the installation process might be unable to download new language packs and download any modules from Addons if the Addons and Translation systems do not acknowledge this version.
If you want to remake the build of a release for comparison and repeatability purpose, make sure you checkout the very same git commit, as the Release Creator will use it to build the code. You can find it on the repository GitHub tags list.
The build will now be delivered to QA team for validation.
You can update the Release Tracker GitHub issue: step “Build” is done.
When QA team has validated the build, this step can be performed.
First, you can update the Release Tracker GitHub issue: step “QA validation” is done.
Only maintainers of the project are granted rights to create new GitHub versions on the PrestaShop repository. However someone who forked the repository can create such a release on his own repository. This can be an opportunity to learn the process, or to reproduce the release for studying purposes.
Open a Pull Request to merge the work you have carried out for the Build: updating the version number and modifying Changelog and Contributors files.
This is the branch you created at step 3 “Create a new branch, commit your changed files” when building the ZIP archive.
The Pull Request must target the
1.7.x.y branch used for building the new release.
When it is merged, tag the last commit on this branch. Not the merge commit that was created by GitHub, but rather the one before. The one that has commit message “// Changelog [version]”.
Open GitHub and go to “Releases” page, click “Draft a new release”.
And publish the new release!
You can update the Release Tracker GitHub issue: step “Release” is done.
This information is currently private to PrestaShop company. It simply involves uploading the ZIP on the website for distribution.
This information is currently private to PrestaShop company. It aims to allow the Addons API to serve modules for the new version.
This information is currently private to PrestaShop company. It aims to allow the Internationalization API to serve localization packs for the new version.
This information is currently private to PrestaShop company.
It aims to update the XML document used by PrestaShop API for the upgrade process. Once updated, the auto-upgrade module is able to parse it and acknowledge the new available version.
You can update the Release Tracker GitHub issue: step “Available for upgrade” is done.
versions.txt- in which you add the new version
versions<major version>.txt- the new release must be added at the end of the file
.travis.yml- to test the image creation with the new release, you can update the test case corresponding to the same major version.
generate_all.sh, all Dockerfile will (re)generated in the folder
Docker Hub is synchronized with the GitHub repository and will quickly provide the new images.
You can update the Release Tracker GitHub issue: step “Docker image” is done.