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

[Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>]

On Wed, 31 May 2023 at 11:24, Erik Schilling <erik.schilling@xxxxxxxxxx> wrote:
>
> Hi all,
>
> After merging of [1] only some cosmetics should be missing from being
> able to publish to crates.io.
>
> First, we would need to agree on a version number (or rather a
> release management process). Rust is suggesting people to follow a
> SemVer approach [2] and I would strongly suggest to stick to that
> recommendation. We _could_ just start releasing with the next libgpiod
> release and have the Rust bindings follow the libgpiod releases. While
> this may seem intuitive to users (they can just spell libgpiod = 2.0.1
> and reason easily about which libgpiod version is in use), it would come
> with a couple of implications:
>
> 1. Users would likely expect new features of a C lib release to also be
>    usable from the Rust crate if it uses the same versioning scheme.
>    So this would also tie the necessary effort to expose those features
>    from the Rust bindings to the release process.
> 2. Supporting multiple versions of the C lib with the Rust bindings
>    would be no problem in general, but would become awkward when trying
>    to replicate the version numbers of the C lib.
> 3. Changes to the Rust bindings would always require an overall version
>    bump.
> 4. There may be a conflict between SemVer bumps for the whole of
>    libgpiod vs a bump that would be required for the Rust bindings only.
>
> This all seems pretty restrictive and undesirable to me... So I would
> recommend to manage the version numbers of libgpiod and the Rust crates
> libgpiod-sys and libgpiod all separately. It may help to think of the
> versions of the Rust crates as ABI versions (the C lib has its own
> ABI version too!). This way we could :just get started with the version
> numbers starting at 0.1.0 and start bumping them as needed for both
> libgpiod and libgpiod-sys independently. Also, this means that uploading
> to crates.io would not be strictly coupled to the release process of the
> C lib and other bindings. That may allow to spread the load a little.
>
> This may be slightly confusing to the user, but I hope it is less
> confusing than the mess of what I listed above? Any opinions?
>
> After agreeing on a versioning strategy, actually publishing to
> crates.io should only require to add version number restrictions to the
> libgpiod->libgpiod-sys dependency. It will then use that version for
> installs from crates.io and use the `path` when building locally.
>
> Once that small change is also done, I think we are ready for
> publishing.
>
> @Bart: How would you prefer to handle the upload of new versions? Or
> would you prefer to be the one doing it or prefer if someone from the
> community handles it? I can offer to help with documentation and setup
> if needed :).
>

For versioning: I'm all for decoupling libgpiod API version from rust
bindings version. I did that for python bindings starting at 2.0
(since they've been published separately on pypi).

For uploading rust crates: I'd love if someone else could do this. I
don't care enough for rust to do a good job at it. :)

Bart

> [1] https://lore.kernel.org/r/20230522-crates-io-v2-0-d8de75e7f584@xxxxxxxxxx/
> [2] https://doc.rust-lang.org/cargo/reference/semver.html
>
> - Erik