Skip to content

Stick to v2 of doctrine/* #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 8, 2020
Merged

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Jul 8, 2020

Fix #18
Similar to #25
I failed at other approaches I was advocating :)
The World is not ready for migration v3, neither for dbal v3 not orm v3 when they'll be released.

To be tagged as v1.1.0

If you need v3, unpack. See #29.

"composer/package-versions-deprecated": "*",
"doctrine/orm": "^2",
"doctrine/doctrine-bundle": "^2",
"doctrine/doctrine-migrations-bundle": "^2"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doctrine-migrations-bundle should probably allow v3 as well though

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, as soon as more ppl + docs have adopted doctrine/migrations v3

@olix21
Copy link

olix21 commented Jul 8, 2020

Me too. I guess they are planning a 2.0 tag with the new doctrine version...

I'm reverting to 1.0.8 so I can keep the doctrine migration v3

@nicolas-grekas
Copy link
Member Author

Don't stick, unpack instead. See #29.

@Addvilz
Copy link

Addvilz commented Jul 9, 2020

Migrations 2 is not forwards compatible with migrations 3. Unpack is not an option, at least for me - I don't want to track each of these dependencies individually across all codebases.

I will pin to 1.0.8 at the time being till orm-pack is updated to 3.

@mmarton
Copy link

mmarton commented Jul 9, 2020

This is not a "fix" to any real problem. If somewone doesn't want the newer version, they could stick to the old version by fixing it in their compose.json, they don't even needed to unpack.
Why would soneone upgrade the orm pack and not upgrade it's dependencies?
Why is it a solution to block progress, make the old one default and enforce everyone to use that (or to unpack)?
Why should it take extra steps to have the latest dependencies if I start a new project?
I've already updated my projects to the v3, took me about 5 minute/project....

@nicolas-grekas
Copy link
Member Author

See #30 about allowing v3 again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tag new versions depending on dependency changes
7 participants