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

Drop ineffective requiredProperties #34

Merged
merged 1 commit into from
Sep 22, 2021

Conversation

rohanpm
Copy link
Member

@rohanpm rohanpm commented Sep 22, 2021

The schema here attempted to require certain properties, but this had no
effect because the correct keyword is "required", not
"requiredProperties". This can be confirmed at
http://json-schema.org/draft-07/schema.

So, in reality we have never required any properties here.
We could now change this to "required" to match the original intent,
but I think it's reasonable to just drop them instead since:

  • adding new required properties is backwards-incompatible. In the
    worst-case scenario it breaks some services; in the best case it
    probably breaks at least some tests.

  • it anyway seems more user-friendly to allow these fields to be
    omitted, since they always have some obvious default value
    which could be provided (such as an empty list or dict). These could
    even be filled in by the library automatically on load, though this
    is not pursued at the moment.

@rohanpm rohanpm marked this pull request as ready for review September 22, 2021 05:09
@rohanpm rohanpm requested a review from a team September 22, 2021 05:09
The schema here attempted to require certain properties, but this had no
effect because the correct keyword is "required", not
"requiredProperties". This can be confirmed at
http://json-schema.org/draft-07/schema.

So, in reality we have never required any properties here.
We could now change this to "required" to match the original intent,
but I think it's reasonable to just drop them instead since:

- adding new required properties is backwards-incompatible. In the
  worst-case scenario it breaks some services; in the best case it
  probably breaks at least some tests.

- it anyway seems more user-friendly to allow these fields to be
  omitted, since they always have some obvious default value
  which could be provided (such as an empty list or dict). These could
  even be filled in by the library automatically on load, though this
  is not pursued at the moment.
@rohanpm rohanpm merged commit 9e97e8b into release-engineering:master Sep 22, 2021
@rohanpm rohanpm deleted the required branch September 22, 2021 22:30
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.

3 participants