Problem
The version of the xgrammar-rs crate (presumably, deliberately) looks very similar to the versions of the upstream xgrammar. But the latest release (xgrammar-rs 0.1.32) incremented the patch version, despite continuing to provide bindings for the old xgrammar 0.1.31.
This is potentially confusing for users, especially the ones coming from the upstream xgrammar README page, which links to xgrammar-rs as a third-party binding.
Possible solution
Ideally, it would be nice to have the version string include upstream xgrammar version as well as the bindings version. Unfortunately, cargo is quite restrictive and requires that the version string is a semantic version, so we can't just do something like upstream_major.upstream_minor.upstream_patch.bindings_major.
One compatible string format could be A.B.C-D, where D is our version. This is accepted by cargo and this version string makes it clear which version of xgrammar is shipped. It also allows maintaining multiple xgrammar-rs branches for multiple upstream xgrammar versions.
The unfortunate side effect is that such a version string is interpreted as a pre-release. For instance, if a requirement in Cargo.toml is A.B.C, cargo won't automatically select A.B.C-D. However, if A.B.C-D is specified with any value for D, cargo will always select the latest one among A.B.C-* (see the cargo reference). In addition to that, the already released versions might need to be yanked and re-released.
Problem
The version of the
xgrammar-rscrate (presumably, deliberately) looks very similar to the versions of the upstreamxgrammar. But the latest release (xgrammar-rs 0.1.32) incremented the patch version, despite continuing to provide bindings for the old xgrammar 0.1.31.This is potentially confusing for users, especially the ones coming from the upstream xgrammar README page, which links to xgrammar-rs as a third-party binding.
Possible solution
Ideally, it would be nice to have the version string include upstream xgrammar version as well as the bindings version. Unfortunately, cargo is quite restrictive and requires that the version string is a semantic version, so we can't just do something like
upstream_major.upstream_minor.upstream_patch.bindings_major.One compatible string format could be
A.B.C-D, whereDis our version. This is accepted by cargo and this version string makes it clear which version of xgrammar is shipped. It also allows maintaining multiple xgrammar-rs branches for multiple upstream xgrammar versions.The unfortunate side effect is that such a version string is interpreted as a pre-release. For instance, if a requirement in Cargo.toml is
A.B.C, cargo won't automatically selectA.B.C-D. However, ifA.B.C-Dis specified with any value forD, cargo will always select the latest one amongA.B.C-*(see the cargo reference). In addition to that, the already released versions might need to be yanked and re-released.