-
Notifications
You must be signed in to change notification settings - Fork 232
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
Policy: make changes to a policy explicit in the policy. #529
Comments
@Retzoh do you still have an opinion on this? |
This could be a good thing to look at for 2.0. How does the immutable nature of Policy work for everyone, and is there any better solution? |
agree Michael I would like to discuss this point |
Is this still a pressing issue we want to address or is it ok to close it for now? |
Eh, I think doing a diff between two JSON blobs is pretty straightforward ... I'm inclined to close. |
Is your feature request related to a problem? Please describe.
I think the current versioning system for policies could be improved to enable easier policy update management. Today you need to create a new policy referencing an incorrect one through the
prev_policy
field to update or cancel it. This means that from the provider perspective, looking at one given policy is not enough to know if they should comply with it or not. You need to look at all of them.Describe the solution you'd like
A solution could be to let agencies update only the ending date of a policy. This way if a policy needs to be updated, the city can just terminate the obsolete version of it and create a new up to date version.
Is this a breaking change
A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
We could also add a new field,
next_policies
, tracking the replacing policies and making it easier to follow the history of changes.The
prev_policy
field could be left for retro-compatibility and / or readability of the history of a policy.I don't think it would be breaking since the
prev_policy
field could still be filled in in the replacing policy.Impacted Spec
For which spec is this feature being requested?
policy
Describe alternatives you've considered
We could just leave it as it is.
The text was updated successfully, but these errors were encountered: