search

cosmos / ibc-rs

Rust implementation of the Inter-Blockchain Communication (IBC) protocol.
Apache License 2.0
181 stars 73 forks source link

Clarify ibc-rs's semantic versioning policy #1240

Closed adizere closed 1 week ago

adizere commented 1 month ago

Contrast with https://github.com/cosmos/ibc-go/blob/main/RELEASES.md

seanchen1991 commented 1 month ago

In what ways do we deviate from the semantic versioning spec?

Given a version number MAJOR.MINOR.PATCH, increment the: 1) MAJOR version when you make incompatible API changes 2) MINOR version when you add functionality in a backward compatible manner 3) PATCH version when you make backward compatible bug fixes

From what I understand based on how we've done releases in the past, it seems we increment PATCH versions when we make compatible bug fixes as well as add backward compatible functionality, i.e. we combine 2) and 3). The MINOR version is incremented when we make incompatible / breaking API changes. Thus far we haven't incremented the MAJOR version, but I suppose that's reserved for state-machine / consensus-breaking changes.

Reaching the v1 milestone typically communicates to users that we don't intend to rock the boat as far as API stability is concerned, but in our case, the MINOR version is what communicates whether API changes were made as part of a release, so is communicating a stable API not part of the v1 milestone?