Skip to content
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

Address deprecations from persistence #7953

Open
wants to merge 1 commit into
base: 2.8.x
from

Conversation

@greg0ire
Copy link
Member

greg0ire commented Dec 12, 2019

A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:

  • using the new namespaces
  • adding autoload calls for new types to types that may be extended and
    use persistence types in type declarations of non-constructor methods,
    so that signature compatibility is recognized by old versions of php.
    More details on this at
    https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

How can I test this on my project?

composer config repositories.greg0ire vcs https://github.com/greg0ire/doctrine-orm
composer require doctrine/orm "dev-address-persistence-deprecations as v2.7.0"
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch 3 times, most recently from 33c9fe3 to 788b5d8 Dec 12, 2019
@greg0ire greg0ire changed the title Address deprecations from persistence WIP: Address deprecations from persistence Dec 12, 2019
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch 3 times, most recently from 271a2ec to b3a221c Dec 12, 2019
@greg0ire greg0ire changed the title WIP: Address deprecations from persistence Address deprecations from persistence Dec 12, 2019
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from b3a221c to 3d9483f Dec 12, 2019
@greg0ire greg0ire changed the base branch from 2.8.x to 2.7 Dec 12, 2019
composer.json Outdated Show resolved Hide resolved
@alcaeus alcaeus self-assigned this Dec 12, 2019
@alcaeus alcaeus added the Bug label Dec 12, 2019
@greg0ire greg0ire changed the title Address deprecations from persistence WIP: Address deprecations from persistence Dec 12, 2019
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch 8 times, most recently from 4c6ee4e to 2905823 Dec 12, 2019
@greg0ire greg0ire changed the title WIP: Address deprecations from persistence Address deprecations from persistence Dec 13, 2019
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from 2905823 to a19296a Dec 13, 2019
Copy link
Member

alcaeus left a comment

LGTM. @nicolas-grekas do you want to give this another look before we merge it?

@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch 3 times, most recently from d76a879 to 5c71e38 Dec 13, 2019
@lcobucci

This comment has been minimized.

Copy link
Member

lcobucci commented Dec 16, 2019

@lcobucci is there a timeline for 2.8?

@alcaeus nope.

@lcobucci lcobucci added Deprecation Improvement and removed Bug labels Dec 16, 2019
@lcobucci lcobucci added this to the 2.8.0 milestone Dec 16, 2019
@lcobucci lcobucci changed the base branch from 2.7 to 2.8.x Dec 16, 2019
@lcobucci

This comment has been minimized.

Copy link
Member

lcobucci commented Dec 16, 2019

@greg0ire is now targeting 2.8.x since it requires a dependency change 👍

@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from a6b7e00 to 605dd9a Dec 17, 2019
@greg0ire

This comment has been minimized.

Copy link
Member Author

greg0ire commented Dec 17, 2019

I rebased 👍

@cybernet

This comment has been minimized.

Copy link

cybernet commented Dec 31, 2019

can be merged ?

UPGRADE.md Outdated Show resolved Hide resolved
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from 605dd9a to 519e792 Jan 3, 2020
@garak

This comment was marked as resolved.

Copy link
Contributor

garak commented Jan 3, 2020

How can I test this on my project?

composer config repositories.greg0ire vcs https://github.com/greg0ire/doctrine-orm
composer require doctrine/orm "dev-address-persistence-deprecations as v2.7.0"

This is not working, it looks like repository is named "greg0ire/doctrine2" instead of "greg0ire/doctrine-orm"

@greg0ire

This comment was marked as resolved.

Copy link
Member Author

greg0ire commented Jan 3, 2020

Thanks for the heads up, I just renamed it!

Copy link
Member

nicolas-grekas left a comment

That's the way to go.
The BC layer will require no maintenance and will fade out with v2 anyway.
Please consider merging asap so we can get free of those deprecation reports that pop up on our CIs or on our repos.

@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from 519e792 to 891ee76 Jan 9, 2020
A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:
- using the new namespaces
- adding autoload calls for new types to types that may be extended and
use persistence types in type declarations of non-constructor methods,
so that signature compatibility is recognized by old versions of php.
More details on this at
https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf
@greg0ire greg0ire force-pushed the greg0ire:address-persistence-deprecations branch from 891ee76 to 9f0c430 Jan 9, 2020
@beberlei

This comment has been minimized.

Copy link
Member

beberlei commented Jan 9, 2020

We released a 1.3.4 of persistence and rolled back the deprecation messages, and will only emit them when 1.4 is released. The idea is that all external code depends on doctrine/persistence version ^1.3 and then the ORM and/or mongodb-odm will raise to 1.4 in the near future when they are compatible. This way we will defer the deprecation messages until we ourselves are compatible.

@cybernet

This comment has been minimized.

Copy link

cybernet commented Jan 9, 2020

#OMG i’m 20 errors free 👍

@@ -25,7 +25,7 @@
"doctrine/dbal": "^2.9.3",
"doctrine/event-manager": "^1.1",
"doctrine/instantiator": "^1.3",
"doctrine/persistence": "^1.2",
"doctrine/persistence": "^1.3.3",

This comment has been minimized.

Copy link
@alcaeus

alcaeus Jan 10, 2020

Member
Suggested change
"doctrine/persistence": "^1.3.3",
"doctrine/persistence": "^1.4 || ^2.0",

This comment has been minimized.

Copy link
@greg0ire

greg0ire Jan 10, 2020

Author Member

I'd do this in a separate PR, once 1.4 is effectively published, cause I'm not going to get a green build otherwise, am I?

This comment has been minimized.

Copy link
@alcaeus

alcaeus Jan 10, 2020

Member

Um, yeah. Absolutely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.