mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
2.6 (dev-master at present) excludes all stable versions of symfony/yaml #5656
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @asgrim on GitHub (Aug 22, 2017).
Originally assigned to: @Ocramius on GitHub.
Latest version is not installable at the moment without explicitly allowing the dev version of symfony/yaml because it's not stable yet. This may have impact on the imminent release of ORM 2.6.
@asgrim commented on GitHub (Aug 22, 2017):
The cause is the
conflictwith any version less than 3.4, introduced in40515472c1@Ocramius commented on GitHub (Aug 22, 2017):
This is hilarious: we finally managed to remove Yaml support 😂
@stof commented on GitHub (Aug 22, 2017):
actually, I would remove the usage of the constant without bumping the min version. This constant was added in symfony/yaml 3.3 (so undefined constant also applies to 3.2 and older in the old code of https://github.com/doctrine/doctrine2/pull/6630/files btw) to add a way to force evaluating keys as string to go toward more compliant parsing by default. Just after the release of 3.3 (so too late to revert the introduction of the constant without going through deprecation), we figured out a better upgrade for users to do (and even 3.3 deprecation warnings suggest the better way now instead of suggesting the constant IIRC): actually putting quotes around the key when the unquoted value would not be a YAML string.
And this means that your code is actually working with any version of the Yaml component (you now have again the same code in your driver than in the Symfony 3.2 time). The bump of the min version was a mistake in #6630 due to a bad analysis of when the constant was available.
@Ocramius commented on GitHub (Aug 22, 2017):
@stof if that's alright, I'll just remove the
conflictthen.Still, had a good and loud laugh :D
@stof commented on GitHub (Aug 22, 2017):
@Ocramius yes, reverting the conflict rule is what you need here.
Too bad that we came up with this
PARSE_KEYS_AS_STRINGSfeature and released it before finding the right change to do (it's actually not the first time this happened to us. We had this in Symfony 2.3 adding synchronized services in the DIC to support better therequestservice, and the RequestStack idea was stuck in discussion while releasing it and so came in 2.4 only and synchronized services became useless... Nobody's perfect).@Majkl578 commented on GitHub (Aug 30, 2017):
See #6658.