There might be a reason to change the pyrefly report json schema in the future, but doing so will be a breaking change. A way around this is to include a schema version number in the json. That way, downstream tools, such as the typestats dashboard upload page (https://jorenham.github.io/typestats/dashboard/report/), can take into account these schema versions, and could even support multiple versions simultaneously.
For inspiration: typestats report ... currently uses a {major}.{minor} versioning scheme. Increments to the minor version are backwards compatible, but will trigger a CI job to regenerate all reports again. Increments to the major version are backwards incompatible, so if you upload an outdated report json to https://jorenham.github.io/typestats/dashboard/report/, it will kindly tell you that you need to update typestats, instead of silently breaking.
There might be a reason to change the
pyrefly reportjson schema in the future, but doing so will be a breaking change. A way around this is to include a schema version number in the json. That way, downstream tools, such as the typestats dashboard upload page (https://jorenham.github.io/typestats/dashboard/report/), can take into account these schema versions, and could even support multiple versions simultaneously.For inspiration:
typestats report ...currently uses a{major}.{minor}versioning scheme. Increments to the minor version are backwards compatible, but will trigger a CI job to regenerate all reports again. Increments to the major version are backwards incompatible, so if you upload an outdated report json to https://jorenham.github.io/typestats/dashboard/report/, it will kindly tell you that you need to update typestats, instead of silently breaking.