Conversation
- Before updating the ORM version
|
See #527 for going to ORM 2.10 |
tofu-rocketry
left a comment
There was a problem hiding this comment.
You planning to squash this? Or at least the individual ORM updates?
What's the symfony/cache about?
Does the composer.lock actually need reviewing, or can we trust in the auto generation?
I was going to leave them as is, that way if we need to roll back versions of ORM we have options other than back to 2.6
Hmm good point... goes digging ah-hah! It was discussed #344 (comment), but the resultant commit message made it's way to the ORM 2.10 commit. I'll update the commit message, and fix the indentation, but basically this 😋: https://github.com/doctrine/orm/blob/2.9.x/UPGRADE.md#minor-bc-break-setup-tool-needs-cache-implementation
I am happy to trust the auto generation 😆 |
ah it's tabs and space 😋 |
- Doctrine 2.9 deprecated doctrine/cache, as a result the setup tool might no longer work as expected without a different cache implementation. - See: https://github.com/doctrine/orm/blob/2.9.x/UPGRADE.md#upgrade-to-29
227dad8 to
281b4be
Compare
ORM 2.9 seems to be as high as we can go now without starting to hit errors that at first glance seem to be because of our version of PHPUnit.
NB: A workable set of packages under ORM 2.10 and 2.11 was once achievable with our version of PHPUnit in #455, but I guess the ecosystem has move on since then - using the commits in #455 would result in some packages being downgraded from the current state of dev.