From: "Erik Schilling" <erik.schilling@linaro.org>
To: "Linux-GPIO" <linux-gpio@vger.kernel.org>,
"Bartosz Golaszewski" <bartosz.golaszewski@linaro.org>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>
Subject: Publishing libgpiod-sys and libgpiod to crates.io
Date: Wed, 31 May 2023 11:24:41 +0200 [thread overview]
Message-ID: <CT0CRWOTJIEO.20BGIDMLFM0E8@fedora> (raw)
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 :).
[1] https://lore.kernel.org/r/20230522-crates-io-v2-0-d8de75e7f584@linaro.org/
[2] https://doc.rust-lang.org/cargo/reference/semver.html
- Erik
next reply other threads:[~2023-05-31 9:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 9:24 Erik Schilling [this message]
2023-05-31 11:05 ` Publishing libgpiod-sys and libgpiod to crates.io Manos Pitsidianakis
2023-05-31 17:25 ` Erik Schilling
2023-05-31 13:31 ` Bartosz Golaszewski
[not found] ` <CT0N67TFERNZ.29590E8F8K2JR@fedora>
2023-06-01 9:30 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CT0CRWOTJIEO.20BGIDMLFM0E8@fedora \
--to=erik.schilling@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=bartosz.golaszewski@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=manos.pitsidianakis@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox