The symptoms are described in ticket EZP-32185, and they are:

if a user running ezplatform 3.2.1 excutes the `composer update` command, the admin interface will break - the icons will not be displayed any more, making some of the buttons completely invisible (see also ticket EZP-3273).

The root cause of the problem is that some of the bundles which make up the ezplatform application will get updated to a version which is not compatible with the "application configuration" that was working in 3.2.1.

This is not seem to be documented anywhere in a changelog / release-notes / update procedure documentation.

Instead, this update procedure is simply officially "not supported". If an end user wants to update his/her ezplatform installation from a minor point release to another minor release, the procedure to follow is described in the documentation, and it is much more complex: it involves adding the ibexa ezplatform repo as upstream git repo, doing git pulls, merges and whatnot.

It is my opinion that this is not a very good solution, and that it could be improved.

• the standard way to upgrade php apps which use Composer is to run `composer update`. It is not run `git pull` first and do diffing and merging (in fact, although I don't necessarily approve of it, I have already seen developer teams who run `composer update` frequently during the development phase, to make sure all their dependencies are up to date)
• different developers team might have different workflows and configurations relating to git branching, merging and upstream repos. The current update instructions are very narrow in their applicability, and presume that forcing every developer to adopt the same patterns in git use is acceptable. I think that it is not
• the current procedure for updating between minor versions is complicated and prone to errors. It could be simpler and safer
• the problem might look complex at first sight, but in the end it is simply a matter of some packages which make up the eZPlatform application breaking their semantic versioning promise. If semver was properly adopted and followed, the assets package which moves its assets to a different directory and is not compatible with old configuration would simply have been tagged with a major version bump, and would thus not have been available for install to end users updating from version 3.2.1 to 3.2.4. Or it could have had in its composer.json a version-incompatibility tag added. Or it could simply have refrained to make a configuration-breaking change until the next major release

I understand that the installation and update procedure for version 3.3 and later is based on Symfony Flex, and that there is little chance that this proposal for improvement will be validated for the 3.2.x line, which is in maintenance mode.

Still, I hope that the above description might be useful feedback to the persons in charge of creating the upgrade/update procedures for version 3.3