Initial version of deprecation process #514
Conversation
Initial version of deprecation process
Fixes a few 404s, specifically on the Glossary page. This does not update the pages/blog/posts/website-analytics-snapshot-2023.md 2023 blog post (which directly links to the json-schema-org.github.io source repository and references behavior that isn't the case for the new website). json-schema-org/community#514 is relevant here, and should likely consider what to do with this link and blog text as part of that PR. This also does not touch files in the _include directory, which are submodules included from the spec repo and will have their own PR there.
There was a problem hiding this comment.
What's the scope of this document? I know the inspiration for it is no longer serving http://json-schema.org/latest, but is this intended to also refer to spec changes? For example, deprecating a keyword? I think that's a different context that would require some different considerations including a much longer deprecation period before removal.
Co-authored-by: Jason Desrosiers <[email protected]>
Co-authored-by: Jason Desrosiers <[email protected]>
AS agreed in the last OCWM #515 I'll add a scope section to make it clear that this is not applicable to the spec development. |
|
I think my suggestion at the OCWM was misunderstood. I wasn't concerned about non-breaking changes. I'm fine with including that, but that wasn't the point. What I was trying to communicate was that we would want to follow this plan for any breaking changes. Deprecation is just one kind of breaking change. I think it would be wise to change some of the wording in this document so that it generalizes to any breaking change, not just deprecation. |
You are right @jdesrosiers. I think you didn't said anything about breaking or non-breaking changes, it is just I choose the wrong words to differentiate the new section with the recommendations. |
Refer to the plan as breaking changes plan instead of deprecation plan.
|
@jdesrosiers I pushed some changes to improve the wording as we discussed in the last OCWM. Please let me know what do you think about this new version. |
Co-authored-by: Jason Desrosiers <[email protected]>
This is the Initial version of a deprecation process to better handle deprecations.
Summary: In #493 we agreed on preparing a deprecation process to communicate the deprecation of the http://json-schema.org/schema redirect. This is a first proposal to have an standard process for cases like this.
Do you think resolving this issue might require an Architectural Decision Record (ADR)? (significant or noteworthy)
No