Sadly, even with the https://docs.conan.io/en/latest/introduction.html#stability commitment, we find that some (mostly experimental) features behave differently between versions, requiring our Jenkinsfile to take different actions depending on the version.
For example, right now we are dealing with differences with conan lockfile creation between "Conan version 1.29.2" and "Conan version 1.26.0".
Although it's possible to obtain the conan version programmatically from within a conanfile, there's no non-brittle way to obtain the conan version externally e.g. from within our Jenkinsfile.
Please support a --json <versionfile.json> option for conan --version so we can reliably consume conan version number information without brittle parsing.
https://docs.conan.io/en/latest/howtos/check_conan_version_in_conanfile.html
Hi @michaelmaguire
The conan --version command follows the convention defined in GNU https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces, accepts --version and outputs Conan version XXX. It should not output anything else, if that is the case then we need to fix that. (did this happen?)
But I am not convinced that going with a --json output is the way to go, I have not seen a single tool that implements something like that (git, cmake, compilers...).
The
conan --versioncommand follows the convention defined in GNU https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces, accepts--versionand outputsConan version XXX.
Thanks for this -- I see now in effect there is already a "specification" of sorts and Conan adheres to it. We can use that.
Great, thanks! That doesn't mean that Conan might eventually have a bug and contaminate the output with other things but if it is not possible to parse and extract the Conan version XXX, then, we will consider a bug and fix it.