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

["Erik Schilling" <erik.schilling@xxxxxxxxxx>]

On Wed May 31, 2023 at 3:31 PM CEST, Bartosz Golaszewski wrote:
> 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).

Yeah, Python bindings are probably in a very similar spot. Would make
sense to follow them I think.

> 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. :)

Viresh: Shall we spread the load? I am happy to set everything up.
But it would be good to have someone else on the list who is using the
bindings actively. :)

- Erik