-
Notifications
You must be signed in to change notification settings - Fork 15.5k
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
[PHP] option exclude backwards compatible proto files #9593
Comments
I think removing the backward compat logic is the way to go at this point. Four years with deprecation warnings seems sufficient. |
The only issue I can think of is for libraries like
|
since the latest release still outputs deprecated files... grep 'is deprecated and will be removed in the next major release' -R path/to/proto -l | xargs rm' |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
We're making a breaking change release now. This is the perfect time to remove these deprecated files. |
Fixes: #9593 PiperOrigin-RevId: 603498316
Fixes: #9593 PiperOrigin-RevId: 603498316
Fixes: protocolbuffers#9593 Fixes: protocolbuffers#15696 PiperOrigin-RevId: 603777295
For PHP all nested messages generate two classes, the current namespaced class and a file to support backwards compatibility with the previous non-namespaced files. There's also a
class_alias
call at the bottom of every nested message. See this PR from almost 4 years ago.As been almost 4 years, these files are now more of a nuisance. I see three potential options here, ranked from least to most risky:
protoc
to not generate these files for PHP (opt-out, most conservative)protoc
to generate these files for PHP (opt-in, could potentially break some very slow to upgrade users)I'm happy to give a PR a try any of these options are possible!
The text was updated successfully, but these errors were encountered: