search

symfony / orm-pack

A Symfony Pack for Doctrine ORM
MIT License
1.82k stars 18 forks source link

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

Closed goetas closed 4 years ago

goetas commented 4 years ago

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 https://github.com/symfony/orm-pack/commit/c8b2fd476a8c9686d752f275d5b607b8101d079d)

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 https://github.com/symfony/orm-pack/issues/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 https://github.com/symfony/orm-pack/issues/18

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

goetas commented 4 years ago

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 commented 4 years ago

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

goetas commented 4 years ago

Should flex unpack automatically while installing the pack packages?

stof commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

indeed

stof commented 4 years ago

Ppl should unpack their deps for greater control.

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

ttcremers commented 4 years ago

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 commented 4 years ago

Reverted in #28

gggeek commented 4 years ago

@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...)