I have a question about versioning of crates that are not published by the same person or organizations, but are designed to be used together in an application.
Specifically, I created a crate plotters-wxdragon that is a backend for plotters. My first thought is that this crate should have its own versioning, since it cannot follow the versions of both plotters and wxdragon crates.
But the documentation of plotters-backend (which defines the interface that my crate implements for plotter compatibility) recommends the following:
We also impose a versioning rule with plotters and some backends: The compatible main crate (plotters) and this crate (plotters-backend) are always use the same major and minor version number. All the plotters main crate and second-party backends with version “x.y.*” should be compatible, and they should depens on the latest version of plotters-backend x.y.*
I understand that plotters-xxx backends developed under the "plotters" organization follow a same-version principle, but it is not really desirable to do so in third-party backends.
In the general case, it’s not possible to maintain this type of synchronization without potentially large costs. Suppose that bar 123.0.0 depends on foo 123.0.0. Then suppose that bar’s authors discover that bar has a bug or highly desirable feature which requires a breaking API change.bar's authors have the following options:
Release bar 123.1.0, a breaking change marked as minor. This breaks dependents written for bar 123.0.0.
Release bar 124.0.0. This means bar is no longer using the same numbering as foo is.
Convince foo to release foo 124.0.0 even though there are no breaking changes in foo, then release accompanying bar 124.0.0. This means that all other crates using foo need to update to stay compatible with the latest, so applications cannot upgrade until the maintainers of allfoo dependents they use have made releases.
Wait to release bar 124.0.0 until foo 124.0.0 is released. This means that bar’s improvement or fix is delayed by foo’s release.
This problem exists whether or not foo and bar are maintained by different people. The only thing that changes if they’re maintained by the same people is that those people can plan out work so that breaking API changes in foo and bar are more likely to occur at the same time.
foo could mitigate this problem by deliberately including gaps in its major versioning, i.e. release 10.0.0, 20.0.0, 30.0.0, and so on, so that bar can release 11.0.0, 12.0.0, etc., but I’ve never seen this actually being done.
Coordinating versions is useful “marketing” / “product labeling” — it can help users understand how to successfully use foo and bar together — but it doesn’t provide any technical benefits.