ElementsProject
Support multiple cln-version in pyln-testing
It is sometimes useful to use pyln-testing also on older versions of Core Lightning. In greenlight we use pyln-testing to test our scheduler which has to support multiple versions of Core Lightning at the same time.
A similar issue exists for plug-in developers that want to support a range of cln-versions.
This PR introduces NodeVersion in pyln-client which can be used to compare the versions lightningd and test if the version is greater or not.
It also modifes pyln-testing so it will only use the --developer flag if it is available.
I got one conceptual question here:
What is the advantage adding the various classes in version.py?
Couldn't we simply parse the version string into an integer value e.g using a function ver_to_int(ver_str) that turns a version string into an int? v23.08 becomes 230800 and v23.08.1 becomes 230801 and v23.08rc3 becomes 230800 as well, according to your ruleset? Versions and their resulting integers are strictly monotone (at least until the end of the century) and we can compare via standard comparsion operators <, >, <=, >= and == instead of parsing an own set of operators for string comparison (from which we only use a check on >=v23.11 for now as far as I can tell).
What do you think about this, do I miss something here? Maybe an advantage of the string based comparison for future extensibility? Otherwise this might safe us approx 290 lines of code to maintain.
I got one conceptual question here:
What is the advantage adding the various classes in
version.py?Couldn't we simply parse the version string into an integer value e.g using a function
ver_to_int(ver_str)that turns a version string into an int?v23.08becomes230800andv23.08.1becomes230801andv23.08rc3becomes230800as well, according to your ruleset? Versions and their resulting integers are strictly monotone (at least until the end of the century) and we can compare via standard comparsion operators<,>,<=,>=and==instead of parsing an own set of operators for string comparison (from which we only use a check on>=v23.11for now as far as I can tell).What do you think about this, do I miss something here? Maybe an advantage of the string based comparison for future extensibility? Otherwise this might safe us approx 290 lines of code to maintain.
You would normally use a standard version comparitor. But this works...
It's a while ago and I don't remember my exact reasoning.
There are a few weird exceptions with versions though. One of them is 1a86e50-modded which I observed in CI.
I might have gone over the top a bit. But I wanted to have one place where we can always hack things in
