Open detlevo opened 1 year ago
I can work with the current implementation although a line like
VERSION = '1.19.14'
would have been better because now I have to extract the version info from the BUILD string. Hopefully the structure of this string does not change too often in the future.
I deliberately called it BUILD
so I can add a version when I've got more time to tinker. As such the existing API should not change, but the BUILD
string could be weird and unpredictable across different boards.
The intent is that the VERSION
would be the last point release, and the PIMORONI_PICO_SHA
would refer to the specific commit and we can probably indicate if something is pre-release (grabbed from CI artifacts rather than a release build) too.
I don't know if there's a better way to handle VERSION
being potentially misleading, but I suspect having it alternate between vX.X.X
and a commit SHA would be a bad idea for anyone who wants to parse it.
You could use semantic versioning and append an 'alpha', 'beta', 'rc' or whatsoever. Having the version info at a specific location knowing that the format is fixed would be appreciated.
Maybe hijacking the issue but what we are also missing is distinguishing between Pimoroni MicroPython and "Vanilla" MicroPython version.
For example if we would use the uos
library and get the system info, then it would be nice to see "Pimoroni" some where in the output. Current output for version 1.22.2
>>> uos.uname()
(sysname='rp2', nodename='rp2', release='1.22.2', version='v1.22.2, picow v1.22.2 on 2024-03-06 (GNU 9.3.1 MinSizeRel)', machine='Raspberry Pi Pico W with RP2040')
Maybe prepend "Pimoroni" in the version=
field ?
Unfortunately the version of the installed library is not available on the device. That causes one to manually keep track of the installed library version of your zoo of devices. I would suggest to implement one of these possible solution.
Regards, Detlev