Closed ethanmsl closed 5 months ago
Many thanks for pointing this out!
I am currently not yet sure what would be the best way forward, since in I think parts of the API can be considered stabilized. Completely switching to alpha versioning might still be the most reasonable option, but I also consider (a) splitting the library into stable core and not-yet-stable parts and (b) completely considering all parts stable and using SemVer correspondingly.
I have now settled for using the stability
crate to mark not-yet-stable items as #[unstable]
. From version 2.x.x
onwards, SemVer will be correctly used for all non-#[unstable]
items.
Many thanks!
From README and docs.rs home page:
However, as of this writing, the feanor-math's reported version is:
1.7.0
The vast majority of the the Rust ecosystem uses SemVer versioning -- which is incredibly useful for understanding what contracts are intact across updates. Reference: SemVer norms reference in Cargo book
Under SemVer breaking changes would either require bumping the the major version each change or remaining in a
0.x.y
version -- indicating that the API has not yet been stabilized.I realize that changing versioning schemes after creation can be quite awkward, but some approach to move to Semantic Versioning would greatly reduce confusion in the Rust ecosystem and, eventually, support adoption. (e.g. Not being able to use version ranges for dependencies, based on API preservation, will make feanor-math unmangeable as a dependency for many crates.)