Feature: keep locked package versions

[boesing]

Q	A
Documentation	yes
Bugfix	no
BC Break	no
New Feature	yes
RFC	no
QA	no

Description

Hey guys, we want to start with the migration to laminas as soon as possible.
After playing around a bit and talking to other developers of my company, I found out, that we have some projects and teams which follow something like "composer update plan". Thus, they're only updating composer for example 4 times a year.
This made me thinking about what that means about the migration to laminas, as the migration tool drops the composer.lock and enforces updating the whole projects dependencies.

To avoid possible issues with other packages or incompatibilities with new minor versions (or possible invalid constraints in the projects composer.json) and to make a clean upgrade path to laminas possible without upgrading the whole package, I've thought about the --keep-locked-versions flag in the migration tool.
It will actually just copy & paste the locked package versions to the composer.json (even if they not directly depended on em due to recursive dependency resolving). After the first composer install (which is adviced in the migration description), the new composer.lock contains all locked versions from the old composer.lock and the only thing changed were the packages of laminas/mezzio.

After this, one could restore his old constraints in the composer.json manually and drop those dependencies, which were never part of the composer.json.

What do you think about this feature?

To proof that the migration still works, I created an example migration of one of my projects:
boesing/zend-expressive-cors#7

Love to get feedback. Thanks in advance.

[boesing]

Hey guys, any feedback on this?
Would really love to see this feature in one of the next releases to provide a more safe way to teams with strict composer update timeframes 😊

I think this will speed up migrations to laminas even off those timeframes.

[boesing]

TBH: I dont get why travis fails due to ocramius package. its not even used in here 🤷‍♂

[weierophinney]

I rebased off of current develop, which removes the dependency on ocramius/package-versions, and allows Travis to build against your branch successfully.

My one question in here: while you can sync the composer.lock with the packages listed in the composer.json, this does nothing to ensure that nested dependencies receive the same version; they will be updated to whatever latest version is allowed by the parent package.

Does this seem like a potential issue, or is the primary point to ensure that the explicit dependencies get the same version installed?

Otherwise, this all makes sense; I just want to ensure we message exactly what this does to end-users.

[boesing]

I've thought about that aswell, thats why the code actually just copy & pastes any package from composer.lock to composer.json.
Thus, every package version should be locked and therefore the whole dependency graph.

Downside of this is, that one has to remove those packages from his composer.json after migration is finished. But this should be very easy with a side-by-side diff of the composer.json as the new packages are added at the very end of each require and require-dev list.
But this is also mentioned in the command documentation.

However, I still have to change the docs if I have time for it. Hopefully at the end of this week.

[michalbundyra]

@boesing Thanks for update. I've added "Awaiting Author Update", so ping us please when the PR is ready to go.

[boesing]

I've added some documentation in laminas/laminas.github.io#51

I guess I've got anything in there. Feel free to have a look.

[michalbundyra]

LGTM 👍

[michalbundyra]

Thanks, @boesing! Merged into develop for 1.1.0 release.