Update the app to v3.2¶
Before you start updating to v3.3, make sure that you are currently using the latest version of v2.5 (v2.5.31). If not, refer to the update guide for v2.5.
To move from v2.5 to v3.3, first, you need to bring the app to version v3.2.
1. Check out a version¶
A. Create branch¶
Create a new branch for handling update changes from the branch you are updating on:
This creates a new project branch (
update-3.2) for the update based on your current project branch.
If it is not added as a remote yet, add an
C. Prepare for pulling changes¶
sort-packages option when updating from <=v1.13.4, v2.2.3, v2.3.2
Composer sorts packages listed in
If your packages are not sorted yet, you should prepare for this update to make it clearer which changes you introduce.
Assuming you have installed packages on your installation (
composer install), do the following steps:
1. Add sort-packages to the
config section in
1 2 3 4 5 6 7
composer require to get Composer to sort your packages.
The following example updates a few requirements with what you can expect in the upcoming change:
1 2 3 4
3. Check that you can install/update packages.
If Composer says there were no updates, or if it updates packages without stopping with conflicts, your preparation was successful.
4. Save your work.
D. Pull the tag into your branch¶
Pull the latest v3.2 tag into the
update-3.2 branch with the following command:
At this stage you may get conflicts, which are a normal part of the update procedure.
2. Resolve conflicts¶
A. Resolve conflicts¶
If you get a lot of conflicts and you installed from the support.ez.no / support.ibexa.co tarball or from ezplatform.com, you may have incomplete history.
To load the full history, run
git fetch upstream --unshallow from the
update-3.2 branch, and run the merge again.
Ignore the conflicts in
composer.lock, because this file is regenerated when you execute
composer update later.
It is easiest to check out the version of
composer.lock from the tag and add it to the changes:
If you do not keep a copy of
composer.lock in the branch, you may also remove it by running:
B. Resolve conflicts in
You need to fix conflicts in
If you're not familiar with the diff output, you may check out the tag's version from the
update-3.2 branch and inspect the changes.
This command shows the differences between the target
composer.json and your own in the diff output.
composer.json changes the requirements for all of the
ibexa packages. Keep those changes.
The other changes remove what you added for your own project.
git checkout -p to selectively cancel those changes (and retain your additions):
no (do not discard) to the requirement changes of
yes (discard) to removals of your changes.
After you are done, inspect the file (you can use an editor or run
git diff composer.json).
You may also test the file with
and test the dependencies by running
composer update --dry-run
(it outputs what it would do to the dependencies, without applying the changes).
When finished, run
git add composer.json and commit.
C. Fix other conflicts¶
Depending on the local changes you have done, you may get other conflicts on configuration files, kernel, etc.
For each change, edit the file, identify the conflicting changes and resolve the conflict.
git add <conflicting-file> to add the changes.
3. Update the app¶
At this point, you should have a
composer.json file with the correct requirements and you can update dependencies.
If you want to first test how the update proceeds without actually updating any packages, you can try the command with the
composer update to update the dependencies.
Now, proceed to the next step, updating the code to v3.0.