The developer installation documentation describes an update workflow (github-clone-org), but this does not resynchronize the Composer lock file with the new git tags.
horde-components install is designed for initial setup only ("Empty or non-existent installation directory") and overwrites composer.json, losing any additional composer require (nag, mnemo, kronolith, etc.).
horde-components github-clone-org updates the git checkouts (fetch + rebase) but does not resynchronize the Composer lock file with the new git tags. As a consequence, composer show reports outdated version labels even though the actual code is up to date. Neither composer update nor composer update "horde/*" fixes this, as Composer considers the lock file already consistent with the constraints in composer.json. This makes composer show output unreliable as a diagnostic tool.
Question:
Is there already a recommended workflow or command to properly update an existing developer installation without losing additional composer require entries and with a reliable composer show output ?
If not, what would you think of a --update option for horde-components install that would:
Run github-clone-org
Regenerate only the path repositories section of composer.json without overwriting additional require entries
Force-resynchronize the lock file by re-resolving path repository versions from current git tags, bypassing Composer's "nothing to modify" optimization
The developer installation documentation describes an update workflow (github-clone-org), but this does not resynchronize the Composer lock file with the new git tags.
horde-components install is designed for initial setup only ("Empty or non-existent installation directory") and overwrites composer.json, losing any additional composer require (nag, mnemo, kronolith, etc.).
horde-components github-clone-org updates the git checkouts (fetch + rebase) but does not resynchronize the Composer lock file with the new git tags. As a consequence, composer show reports outdated version labels even though the actual code is up to date. Neither composer update nor composer update "horde/*" fixes this, as Composer considers the lock file already consistent with the constraints in composer.json. This makes composer show output unreliable as a diagnostic tool.
Question:
Is there already a recommended workflow or command to properly update an existing developer installation without losing additional composer require entries and with a reliable composer show output ?
If not, what would you think of a --update option for horde-components install that would: