Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add a table to summarize the modes #10067

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Add a table to summarize the modes #10067

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions components/phpunit_bridge.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,6 +200,26 @@ the ``vendors`` directory will make the test suite fail, while deprecations
triggered from a library inside it will not, giving you the best of both
worlds.

Here is a summary that should help you pick the right mode:

+----------------+-----------------------------------------------------+
| Mode | Recommended situation |
+================+=====================================================+
| strict | Recommended for actively maintained projects |
| | with little to no dependencies |
+----------------+-----------------------------------------------------+
| <some integer> | Recommended for projects that you cannot |
| | immediately fix but don't want to make worse. |
| | Can be used to transition from one mode to another. |
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we have a bit more information about what integers you can use here? ie. What's the min/max? Is a lower number more strict or less strict?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This column shows no description, even for other modes. It only shows a recommendation. That particular mode is already documented above.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah fair enough. As long as it's documented somewhere 👍

+----------------+-----------------------------------------------------+
| weak_vendors | Recommended for libraries that use |
| | the deprecation system themselves and |
| | cannot afford to use one of the modes above. |
+----------------+-----------------------------------------------------+
| weak | Not recommended; will probably lead to |
| | a big refactoring. |
+----------------+-----------------------------------------------------+
Copy link
Member

Choose a reason for hiding this comment

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

I like this new table! But, which mode should I use in my project? Most projects either:

A) Have deprecations & know about them... and just want to report them at the bottom of their tests (but not cause failures)

B) Do not have deprecations and want to keep it that way. New deprecations should cause the tests to fail.

What should I have for (A)? And is (B) strict? Or would weak_vendors be better (i.e. only tell me about my deprecations)?

Copy link
Contributor Author

@greg0ire greg0ire Jul 17, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Right now, weak is not good for A, because it does not display deprecations, and I couldn't convince people to change this. At work, I observed that people are using weak_vendors to achieve A, although it's not meant for that. For B, you should use strict if you can. If you're a library and i turns out not to be realistic, for instance if the build fails on your contributors PRs because of unrelated changes in new minor versions of your dependencies, you might be better off with weak_vendors, which will let you focus on your deprecations (trigger_error calls you make in code you should no longer call), and slightly postpone fixing deprecations in your dependencies because of calls you should change.


Disabling the Deprecation Helper
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Expand Down