Version numbering

[thomwiggers]

We're currently using the liboqs version numbering scheme, which does make it clear which version we're bundling. However, that also means that we can't really release patch versions. This is sometimes a problem: #189

One possibility would be to do the following: Release 0.7.2 as 7.2.0 so that we can actually issue patch releases.

[vt-alt]

Is it possible to set version to 0.7.2.1?

[thomwiggers]

AFAIK no, that's pretty much the point of this issue.

[thomwiggers]

@dstebila what do you think?

[dstebila]

If you're limited to x.y.z, then perhaps what you can do is increment z to e.g. 0.7.3? The convention being that 0.7 is the liboqs release series with particular updates within that, and you're matching the liboqs 0.7 release series with your own updates.

[thomwiggers]

I'm afraid that this would get confusing as to which version of liboqs we're packaging though...

[dstebila]

Well, yes, but I don't know what other options there are.

[thomwiggers]

What do you think about basically moving OQS versioning one position to the left? ie. 0.7.2 -> 7.2.0?

Another option could be to do 0.7.2 -> 0.72.0 now that I think of it. I kinda like that as it preserves the "0.-ness" of the release.

Or doing 0.7.2 -> 0.7.200 giving us two positions for patches

[dstebila]

Oooh, I like 0.7.200. I had also thought of the 7.2.0 idea but it seemed too drastic, and would lose the oomph of a 1.0 when it happens.

[thomwiggers]

Okay at some point I will transition over to that versioning scheme.

[thomwiggers]

Starting from 0.8.0, we will follow this versioning scheme.

[thomwiggers]

Oh, crap: this doesn't actually work for versions like 0.8.0: Rust wants to simplify 001 to 1 which breaks this.

[thomwiggers]

Perhaps we do need to move to the 0.80.0 scheme...

[tranzystorekk]

One option to resolve this is to version the crates in a semver way uncoupled from liboqs version, but append a build annotation with liboqs version, like libgit2-sys does (crate_ver+liboqs_ver e.g. 0.8.1+0.8.0), not sure yet how that treats backwards compatibility though

[thomwiggers]

TIL that format. It does seem that it's completely ignored and I'm not sure how visible that would be to users, though...

https://doc.rust-lang.org/cargo/reference/resolver.html#version-metadata

[tranzystorekk]

At the very least it's visible in crates.io and Cargo.lock entries; since we already instruct users to do oqs = "*" in Cargo.toml, it doesn't seem intrusive.

[thomwiggers]

I mean, specifying oqs = "*" in the README is in part because I can not be trusted to keep it up to date 🙈

[thomwiggers]

But if we do the a.b.c+liboqs-e.f.g approach, how do we bump the version in a way that distinguishes it from the liboqs versioning... 🤔

[tranzystorekk]

I'd assume following semver as close as reasonable, e.g.:

• patch bumps on bugfixes to the rust wrapper API and semver-compatible liboqs bumps
• minor bumps on breaking changes to the rust wrapper and semver-incompatible liboqs-bumps (as long as we're on a 0.y.z version that allows this per semver rules)
• exceptions to the above resolved on case-by-case basis

[thomwiggers]

I have updated the versioning scheme and we're no longer following upstream.