gltf-json 1.3 breaks semver

[Ralith]

https://github.com/gltf-rs/gltf/pull/381 changed the type of a public field without bumping the major version number of gltf-json. This broke my code.

[kpreid]

The same change also broke my glTF export code. I'm aware that this is an intentional choice regarding the versioning of gltf-json, but I'd like to ask you to reconsider it in the future. As far as I'm aware, the only way to generate glTF files (without writing a set of serde structure types from scratch) is to depend directly on gltf-json and use its structure fields.

[kpreid]

And with the latest release I'm reminded of more ways this is a problem: if something in the dependency graph starts to depend on a newer gltf-json, and gltf is also in the graph but nothing depends on the latest version, then Cargo will update gltf-json without gltf, producing a broken build.

Please start using accurate semver for gltf-json — any time a type is changed incompatibly etc., its major version must be bumped. (Yes, this means it must go out of sync with gltf. But at least until gltf 2.0.0 comes along, you can have gltf 1.5 paired with gltf-json 5.0.0 and so on.)

https://crates.io/crates/cargo-semver-checks can help validate that the version is properly incremented when changes occur.

[alteous]

Okay I see this situation is clearly irritating lots of people. I will make the next release 2.0, ensure the semantic versioning applies to the underlying data structures thereon. This will likely entail merging gltf-json with the main crate. cargo-semver-checks is a good suggestion.