Versioning of `ctru-sys` crate
ian-h-chamberlain opened this issue · comments
Pick initial numbers for each crate and coordinate publishing a release!
In my opinion,
ctru-rs
can release with a generic version number (like1.0
or0.5
), and the same can be said forpthread-3ds
andlinker-fix-3ds
. However, I would like to underline the importance ofctru-sys
's version number, since we could release it with the same version number oflibctru
(which would double down as a "supported version" number). We'd need to be careful about doc generation though, since we wouldn't be able to easily make a patch release.
Originally posted by @Meziu in #97 (comment)
This is an interesting idea I hadn't considered before! For inspiration I thought I'd look at some other sys
crates, and I found this which looks kinda interesting: https://gitlab.com/taricorp/llvm-sys.rs#llvm-compatibility
Basically, we could have a ctru-sys
version 21.2.x
for the current release, and bump the minor version whenever we regenerate bindings for a new patch of libctru
. This would also allow us to make docgen improvements, etc. as a patch version on the crate instead.
In the case of llvm-sys
, they have some checks in place to verify library versions at build time. It might be harder to do that with libctru
, since it's just a static library, but I was thinking there might be some ways to check it with dkp-pacman
/ pacman
, and spit out a build warning if the versions mismatch, which would be displayed if the build failed (link errors etc).
Opening this issue to track + discuss the possibilities.
Nice research! I really like the idea of the version number being related (we could specify this to the user in the README). I'm not an expert on GitHub CI, so I don't know the actual limitations, but retrieving libctru
's version number should be as easy as:
sudo dkp-pacman -Si libctru | grep "Version\s*:\s\K.*" -o
As mentioned in #133 (comment) it sounds like we will probably move to a different versioning scheme than we had before, since that PR is now generating bindings on the fly instead of checking them into the repo. With those changes, I guess we can reset the ctru-sys
version (maybe to 0.2.0?) and require a minimum libctru
version somewhere in its build script.
I guess in principle, ctru
depends on the libctru
version more than ctru-sys
does, so perhaps it makes more sense to have the minimum libctru
version check in ctru
? Otherwise, we'd probably have a kind of indirect relationship from ctru
-> ctru-sys
-> libctru
, which maybe is fine but perhaps a direct relationship would be better.
On a semi-related note, I was debating whether it might be worth it to wrap up the bindgen stuff that @FenrirWolf did into a separate crate so we could reuse it for citro3d-sys
(and possibly citro2d
in the future)? I have been thinking about creating a common tools
type of repo to put common stuff in, like reusable Github Actions, and maybe something like this would make sense to put in there too. The downside of an extra crate would be yet another package to put on https://crates.io which is kind of a pain and maybe not worth it. Thoughts?