Skip to content

[Serializer] Add deprecation notices #18583

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

Conversation

theofidry
Copy link
Contributor

Q A
Branch? 2.3+
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets #17140
License MIT
Doc PR none

Since #17140 (de)normalizerCache are not used anymore and according to this comment this should have been deprecated since then.

@dunglas
Copy link
Member

dunglas commented Apr 18, 2016

👍

@nicolas-grekas
Copy link
Member

This should be applied on 2.8 to me.
👍

@theofidry
Copy link
Contributor Author

@nicolas-grekas why in 2.8 only if it was planned to be removed since 2.3?

@jvasseur
Copy link
Contributor

Should have done this PR a long time ago.

We can't add a deprecation in a patch release, so this should be deprecated in 3.1 and removed in 4.0.

@nicolas-grekas
Copy link
Member

@jvasseur but you have to consider that the corresponding code has already been removed from 3.0. That's why this should go on 2.8 to me: earlier would break the not-in-patch-release constraint, and 2.8 is really the branch were we missed adding the notices while we removed the code on 3.0.

@theofidry
Copy link
Contributor Author

but you have to consider that the corresponding code has already been removed from 3.0.

AFAICS this code is still in 3.0 :/ https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Serializer/Serializer.php#L65

@jvasseur
Copy link
Contributor

The property is still in 3.0, but not the code that read from it in case someone was filling the cache manually (it was lost in a merge).

@theofidry
Copy link
Contributor Author

The property is still in 3.0, but not the code that read from it in case someone was filling the cache manually (it was lost in a merge).

@jvasseur that's what you removed from #17140 right?

But the issue is that it's still in 3.0 as protected in an extendable class, so it can still be potentially used. As it has never been deprecated clearly, removing it at this point would be a BC break. So maybe I should add "will be removed in 4.0".

That's why this should go on 2.8 to me: earlier would break the not-in-patch-release constraint, and 2.8 is really the branch were we missed adding the notices while we removed the code on 3.0.

@nicolas-grekas I'm not sure to understand why this would break the not-in-patch-release constraint. But as the code is still present in 3.0 should this be added to master or 3.0 instead?

@jvasseur
Copy link
Contributor

@theofidry in #17140, I removed the code writing into the normalizer cache but not the code reading from it (https://github.com/symfony/symfony/blob/2.3/src/Symfony/Component/Serializer/Serializer.php#L232-L235) in case someone was manually filling the cache.

My plan was to add the deprecation in 3.1 (next minor release) and remove the property in 4.0

@nicolas-grekas
Copy link
Member

good to me on master

@theofidry
Copy link
Contributor Author

good to me on master

Closing in favour of #18588 then.

@theofidry theofidry closed this Apr 19, 2016
nicolas-grekas added a commit that referenced this pull request Apr 19, 2016
This PR was squashed before being merged into the 3.1-dev branch (closes #18588).

Discussion
----------

[Serializer] Add deprecation notices

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | #17140
| License       | MIT
| Doc PR        | none

As discussed in #18583, add deprecation notices to `master` instead.

Commits
-------

d3063ed [Serializer] Add deprecation notices
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants