Closed oxisto closed 11 months ago
Seems reasonable , although raises the question:
Is the /v4 version frozen and will only receive security and critical bug fixes?
I would say so. I am not sure if it makes sense to make a new patch release just with this deprecation notice. Maybe we wait until there is a real need for a release?
Tbh, I think that's what migration guides are for, or for an unreleased upcoming version that's in development. But retroactively adding a deprecation notice (to a "frozen" version) and cutting a release feels a bit off.
Also, some users are perfectly content with the /v4 version and it doesn't make that part of the API "wrong".
No blockers from me though, I trust your judgement and don't have a strong opinion on this one.
Tbh, I think that's what migration guides are for, or for an unreleased upcoming version that's in development. But retroactively adding a deprecation notice (to a "frozen" version) and cutting a release feels a bit off.
Also, some users are perfectly content with the /v4 version and it doesn't make that part of the API "wrong".
No blockers from me though, I trust your judgement and don't have a strong opinion on this one.
Makes sense! I have modified the migration guide in the PR dealing with the validation API, this seems to be a better approach.
This PR adds a deprecation notice to
Valid()
to inform users of our v4 branch, that direct usage of the function in a call is discouraged, since v5 changes the way theClaims
interface looks like. This needs to be backported to the v4 branch and released as v4.5.1See #348 for an extended discussion