Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
JSON backwards compatibility policy and tooling.
See original GitHub issueInspired by #4318 @balopat wants a policy on how we support loading json data from deprecated or deleted classes. We expect data to live statically longer than actively maintained code bases.
Similarly, we should revisit our tooling support for maintaining JSON backwards compatibility. Currently, if the structure of a class is changed, the contributor should rename the existing test data to name.json_inward and add a new name.json with the new structure. This procedure happens somewhat infrequently and isn’t well known. It’s hard to tell from GitHub diffs if it’s been done correctly.
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Confusion about this came up in the 3/30/2022 cirq cync, strengthening the case for documenting this.
The ask for documentation is a good one and will be easier than the second part of the original post in this issue, which is to have better tooling to enforce the currently de facto policy that documentation would make de jure.
Specifically: we could have a CI check that mandates the json_test_data *.json files are never modified! This would involve reworking the current json_inward scheme where any given json file could be annotated as “inward” without triggering a git diff.