Re: Publishing libgpiod-sys and libgpiod to crates.io

["Erik Schilling" <erik.schilling@linaro.org>]

On Wed May 31, 2023 at 1:05 PM CEST, Manos Pitsidianakis wrote:
>
> Breaking changes are inevitable. The libc crate follows a nonsemver 
> scheme (0.2.144 and bump the patch number by one for every release) 
> which breaks stuff all the time, or at least it used to when it was at 
> its early stages. There are ways to get around breakages in case of a 
> crate lib being a transitive dependency but has different versions: 
>
> https://github.com/dtolnay/semver-trick
>
> I believe following libgpiod's version scheme directly is what would be 
> best and intuitive. -sys crates are not usual crates and users know 
> this. It'd be cool to not have to bump the bindings crate version but I 
> don't think it's a problem.

How would you deal with the libgpiod (Rust) -> libgpiod (C) dependency
here? Should we request an exact match via pkg-config (or at least a
lower floor that would equal the version of the C lib?).

I think that there would be no good reason not to support older versions
of the C lib (at least as long as sensible!). But it may be a bit weird
if the Rust crate has a matching version scheme but then automatically
disables features when building against an older system library... A
separate version scheme might make that a little more explicit. But I
got no particularly strong feelings about this.

> This is how openssl{,-sys} works, if I am  not mistaken.

openssl does not seem to follow this for neither -sys, nor the main
package. It would also probably be a weird thing to do since it supports
other backends like boringssl.


> All in all, in crates.io follow its conventions unless there's no way to 
> do so.

I think all of the options that I listed in my initial mail would follow
the crates.io conventions and I strongly agree that we should follow the
existing conventions. What to pick seems to mostly depend on how we want
the release process to look like.

- Erik