Binary format versioning

[JukkaL]

I want to keep the extension backward compatible once we've made the first public release. Add a version number parameter to the public API, so that we can continue to support old mypy versions. Ideally updating ast-serialize to a new version should not break mypy. If we adopt semver, this would mean that we don't plan to release a 2.0 version. We can drop support for old format versions after a suitably long deprecation period (multiple years).

The main expected format changes are from supporting for new Python features, and fixes to bugs. We can gate new AST features behind a version check. Bug fixes may also have to be gated, if we need to add new data fields in the serialized data, for example.

We'd probably want to test against older mypy versions in the CI so that we don't accidentally break backward compatibility.

[ilevkivskyi]

Btw I was thinking about this, and I am not sure why do we need to be so strict about this. I understand this argument for librt which potentially will be a dependency for a lot of other distributions, while ast_serialize will likely be used only by mypy and maybe a handful of other tools.

I think we can simply do the following: when mypy is released, place ast-serialize>=x.y.z;<x+1.0.0 in requirements, where x.y.z is the ast_serialize version at the time of mypy release. Then we can release backwards incompatible changes without risk of breaking old mypy versions. We would still do this rarely, only if really necessary.

[JukkaL]

That sounds reasonable. We'd have an option of making backward incompatible changes even if we have no concrete plans (or even the intention) to do this.

[JukkaL]

This is now supported.