Semantic versioning? Or: document versioning policy

[dralley]

We are not 100% sure how to set the bounds when pinning the version of PySequoia, since the versioning policy doesn't seem consistent with semantic versioning - APIs could be changed or removed in "minor" or "patch" releases.

That makes it difficult to use open-ended dependency specifications and also potentially creates problems for dependabot.

[wiktor-k]

Ack. I think we should be keeping track of breaking changes and if they appear, bump the major version (does python support 0.x -> 0.y being major version bump like Rust?).

Also, we could add a test which runs the existing code against README.md from last tag, which would (somewhat) validate the API contract still holds.

I'm open for suggestions 👋

[dralley]

Any version of 0.x moving to a new version of 0.x+1 can be a breaking change, that's fine. It's more the "patch" version (as in major.minor.patch) having breaking changes that is a problem, normally that's reserved for bug fixes and security fixes, not anything which changes the API (additions or removals).

So according to semantic versioning, subsequent releases which included features or API changes would proceed from 0.2.x, 0.3.x, etc. And releases that only included bugfixes without API changes would only bump the patch e.g. 0.2.1, 0.2.2, 0.2.3

And then w/ a non-zero major version, breaking changes would require major version updates. But that's not an immediate concern or anything since it's unlikely that 1.0 will be any time soon.

[wiktor-k]

Okay, so it works exactly as in Rust, that's great to hear.

I'll see if I manage to write a CI job to verify that the semantics didn't change (at least according to the README) but from now I'll at least be... careful about versioning here 😅

Thanks for the input, I'll close this ticket when a new version is released. 👋