8000 [Validator] Email constraint strict option disappeared from docs · Issue #11608 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

[Validator] Email constraint strict option disappeared from docs #11608

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

Jump to bottom
Closed
guilliamxavier opened this issue May 27, 2019 · 5 comments
Closed

[Validator] Email constraint strict option disappeared from docs #11608

guilliamxavier opened this issue May 27, 2019 · 5 comments
Labels
Validator

Comments

@guilliamxavier
Copy link
Contributor

... between 4.0 and 4.1.
Even if deprecated (and superseded by the new mode option) in 4.1, it still exists (until 5.0 I guess).
Compare with e.g. the checkHost/checkMX options (marked as deprecated).
Cf #8487 (comment)
@OskarStark
Copy link
Contributor

But it didn’t disappear, it’s just moved unter the „mode“ option. Is this what you meant?

@guilliamxavier
Copy link
Contributor Author

I meant that (when comparing with the 4.0 docs) the 4.1+ docs give the wrong impression that the strict option (bool) has been replaced by the mode option (string), i.e. that 4.0's @Assert\Email(strict = true) does not work anymore on 4.1+ (and requires to be changed to @Assert\Email(mode = "strict") immediately on upgrade), while it has only been deprecated (because superseded) but still exists and works.

In other words, I think that #8487 should not have modified the doc of the existing strict option to integrate it into the new mode option, but rather should have copied its description (and adapted it) for the "strict" value of the new mode option and just annotated the original option as "deprecated since 4.1" (like e.g. the checkHost option in 4.2+).

Does that make sense?

@OskarStark
Copy link
Contributor

From your comment... it makes sense, not quite sure why we did it this way.
@javiereguiluz can you help here?

@xabbuh
Copy link
Member
xabbuh commented Jun 16, 2019

IIRC we tried not to document deprecated features. While that's good for most articles we should probably keep them in the reference but add a deprecation warning instead.

@guilliamxavier
Copy link
Contributor Author

It guess that's not worth keeping this open any longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Validator
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@OskarStark @xabbuh @guilliamxavier
0