Drop version constraint to allow future package releases (or abandon package)

[goetas]

I can immagine that this is going to be a bit controversial, but I'm not sure if this package was a good idea.

When users use symfony/orm-pack they get some doctrine packages as "doctrine/doctrine-migrations-bundle", versions ^1. or ^2.0,

When doctrine/doctrine-migrations-bundle 3.0 will be released (or orm 3.0 or dbal 2.0), the only way to allow the upgrade it is to allow it in this package, as example defining doctrine/doctrine-migrations-bundle: ^1.3|^2.0|3.0 (an example was c8b2fd4)

But since that was a minor/bigfix release, any user that had installed symfony/orm-pack got automatically installed (as bugfix) doctrine/doctrine-migrations-bundle 2.0 that was a major release with BC breaks. This already was reported in #15, I'm not aware of packs being unpacked by composer... is that true?

My proposal to remove the version constraint has the same disadvantages, but does not oblige the doctrine team to keep updated this repo each time there is a major release on doctrine.

Another solution is that each time a major release is added in the constraints, this package should release a major release, in this way we avoid delivering unexpected major releases. Similar as #18

A third solution (that does not exclude the previous one) is to deprecate this package and let users install what do they need.

[nicolas-grekas]

Ppl should unpack their deps for greater control.

[goetas]

Ppl should unpack their deps for greater control.

how should that happen? is there any tool or explicit flow to do that? if is just "people should" then "people won't"

[nicolas-grekas]

Sure, flex provides an "unpack" composer command exactly for this purpose.

[goetas]

Should flex unpack automatically while installing the pack packages?

[stof]

This is a big issue if you don't unpack, as it means projects will silently upgrade to the new major version. This means that this pack does not follow semver at all.

[goetas]

I think that my proposal of

Another solution is that each time a major release is added in the constraints, this package should release a major release, in this way we avoid delivering unexpected major releases. Similar as #18

should solve the issue...

[stof]

indeed

[stof]

Ppl should unpack their deps for greater control.

if the pack has a * constraint, unpacking will still use *...

[ttcremers]

Ppl should unpack their deps for greater control.

For those who people that, should unpack their packs for greater control: http://fabien.potencier.org/symfony4-unpack-the-packs.html

[nicolas-grekas]

Reverted in #28

[gggeek]

@nicolas-grekas I did try this morning a composer-upgrade of an app from sf 4.4.5 to 4.4.11.
Despite your fix in #28, I still got MigrationsBundle bumped from 2.x to 3.01, which broke because of BC in configuration (which is afaics not handled automatically by any recipe/update-script).
I am not sure why this happened - maybe because the original composer.json file had a dependency on "symfony/orm-pack": "*", which pulled in orm-pack 2.0 ?

ps: I now found out about recent changes which make packs be unpacked oob on app install, which is a behaviour I am happy with. If my understanding is correct, that is the current solution to the problem of pack versioning vs. pack-deps versioning. It seems that pre-existing sf apps are not taken into account correctly though...)