Versioning of ctru-sys crate

[ian-h-chamberlain]

Pick initial numbers for each crate and coordinate publishing a release!

In my opinion, ctru-rscan release with a generic version number (like 1.0or 0.5), and the same can be said for pthread-3dsand linker-fix-3ds. However, I would like to underline the importance of ctru-sys's version number, since we could release it with the same version number of libctru (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.

[Meziu]

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

[ian-h-chamberlain]

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?