Skip to content
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

Add deprecation notice to Valid() #350

Closed
wants to merge 1 commit into from
Closed

Add deprecation notice to Valid() #350

wants to merge 1 commit into from

Conversation

oxisto
Copy link
Collaborator

@oxisto oxisto commented Sep 27, 2023

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 the Claims interface looks like. This needs to be backported to the v4 branch and released as v4.5.1

See #348 for an extended discussion

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 the `Claims` interface looks like. This needs to be backported to the v4 branch and released as v4.5.1
Copy link
Member

@mfridman mfridman left a comment

Choose a reason for hiding this comment

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

Seems reasonable , although raises the question:

Is the /v4 version frozen and will only receive security and critical bug fixes?

@oxisto
Copy link
Collaborator Author

oxisto commented Oct 2, 2023

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?

@mfridman
Copy link
Member

mfridman commented Oct 4, 2023

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.

@oxisto
Copy link
Collaborator Author

oxisto commented Oct 5, 2023

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.

@oxisto oxisto closed this Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants