Version numbering about liboqs-rust HOT 19 CLOSED

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.

from liboqs-rust.

Is it possible to set version to 0.7.2.1?

from liboqs-rust.

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

from liboqs-rust.

@dstebila what do you think?

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.

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.

from liboqs-rust.

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

from liboqs-rust.

Starting from 0.8.0, we will follow this versioning scheme.

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.

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.

from liboqs-rust.

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

from liboqs-rust.

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... 🤔

from liboqs-rust.

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

from liboqs-rust.

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

from liboqs-rust.