Test matrix for hidapi release #376
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi#376
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It seems to me it is a good idea to have the test matrix, similar to the following for libusb-1.0.25rc1.
macports seem to provide a good one for macOS support.
Ref: https://ports.macports.org/port/hidapi/details/
From here for HIDAPI Version: 0.11.2
https://ports.macports.org/port/hidapi/details/
A question here - what do we test by this?
If just to verify that it builds - Github Actions / Appveyor / builds.sr.ht is an indication as well.
The idea is not only to carry out build test, but also test with a few real devices (USB/Bluetooth) using hidtest (hidapitester is another good one) and other applications dependant on hidapi.
Ref: similar discussion in libusb
It will be good to document some known good devices to carry out the tests.
The other thing is to see the operating systems the contributors are able to test: eg: Windows versions, macOS versions, Linux and FreeBSD.
For example, does it make sense to still support Windows XP and Vista? Or old macOS versions? Or very old Linux versions?
For as long as it doesn't require the actually effort / workarounds on a code level to support those.
I'm ready to release a
v0.12.0.How do we want to proceed with the test matrix for it?
@Youw I am okay with either of the following.
Just release v0.12.0 as it is. Right now I tend to think hidapi is rather stable so this is an okay option.
Release 0.12.0rc1 first and then wait for two weeks to release v0.12.0 so that people can test hidapi on different operating systems and different devices to see if there are regressions. It would also be good to check the major language bindinges (eg: cython-hidapi and node-hid).
Reference: libusb 1.0.26-rc1 test matrix
If we go with this idea I should be able to test under the following system. I will use CMake on most of the systems. Then I will also test the VS solution using VS2019.
macOS 12 ARM64 (mac Mini M1)
macOS 12 x86_64 using Rosetta Translation, not native (mac Mini M1)
Linux x86_64 (Ubuntu 20.04)
Linux ARM32 (Raspberry Pi 400 running Raspberry Pi OS Bullseye 32 bit)
Linux ARM64 (Raspberry Pi 400 running Raspberry Pi OS Bullseye 64 bit)
Windows VS2019 64 bit (Windows 11 x64 laptop)
Windows VS2019 32 bit (Windows 11 x64 laptop)
Windows MinGW 64 bit (Windows 11 x64 laptop)
Windows MinGW 32 bit (Windows 11 x64 laptop)
I can not test macOS Intel but I am sure there are people who can test it. Same for FreeBSD.
Then I am probably not good at testing cython-hidapi and node-hid but again other people can test. I will try to test them as well.
https://github.com/libusb/hidapi/issues/407
Close this as #407 has been raised.