Define policy for handling versions of the vendor library

[newAM]

1. How should vendor library updates be handled?
   a. support only the latest
   b. support multiple versions
2. If supporting multiple versions, with what method?

---

The most common method of supporting multiple versions of a library with C FFI is feature flags, e.g. vendor_1_4_8 would enable version 1.4.8, and vendor_1_4_22 would enable 1.4.22. The best example I have seen of this in action is ffmpeg-sys.

However, as I recently learned from #15 cargo features should be additive because of feature-unification.

Are there any *-sys style crates that have other ways of handling this?

[Grinkers]

I was about to suggest A until there's a reason to do more work, thinking FTDI's D2XX drivers were super stable... but apparently linux got a new version on 2020-12-21 and macos on 2021-01-21... but I still think A, at least until there's a good reason why we shouldn't.

https://ftdichip.com/drivers/d2xx-drivers/
to make things worse, the versions are different on different platforms.

[Grinkers]

As I was looking into upgrading to 0.8.1, I found that the updated vendor version broke static linking on windows (which CI doesn't test against).

It's already been fixed by FTDI. PR here #38

This probably won't be the last issue (and it's impossible to test all situations). I think this shows that we need to separate this crate's versioning with FTDI's versioning.

[Grinkers]

#40 makes option 2, supporting multiple versions, much more annoying. I think it makes sense to forgo versions that need legacy_stdio_definitions.lib on Windows.

[newAM]

I need to research more on what other strategies for handling multiple versions of an underlying library are out there; do you know of any others? I have never seen a workspace approach with a crate per version, I wonder if that would be better or worse than feature flags. It would definitely help with the annoyance that is Windows versioning not matching Linux/Mac.

I am a little afraid of the maintenance cost associated with the cartesian product of targets and versions, but at the same time there is a good reason for it.