CasADi is a symbolic framework for numeric optimization implementing automatic differentiation in forward and reverse modes on sparse matrix-valued computational graphs. It supports self-contained C-code generation and interfaces state-of-the-art codes such as SUNDIALS, IPOPT etc. It can be used from C++, Python or Matlab/Octave.
When running using casadi build from source using branch current main:
$ python -c "import casadi;print(casadi.__version__)"
output: 3.6.3-181-g36d4dd629
expected output: 3.6.5-6-g36d4dd629
As far I understand:
If the current repository node is not a release, state defined by the CMake variable IS_RELEASE a "+" is apppended "CASADI_VERSION" in CMakeList.txt this cause the python package to output CasadiMeta.git_describe() instead of casadi.CasadiMeta.version()
CasadiMeta.git_describe() store the value of git describe --first-parent HEAD at time of compilation
git describe --first-parent HEAD output the last annotated tag (tags with a descriptions) , historically it seems some release tags were annotated ~1/4 were not.
git describe --tags --first-parent HEAD will consider also lightweight tags but this would include also tags with format nightly-* which are not very informative in terms of version number
Not a really problem because:
The output of git describe accurately identify the state of the repository at time of compilation
One can always access the casadi.CasadiMeta.version() to check the "release-style" version format
Comments:
I believe the format: <some-tag-in-the-past>-<number-of-commits> is not the most intuitive.
casadi.__version__ from not releases can output something like casadi.CasadiMeta.version() with $(git rev-parse --short HEAD) appended. I guess the price is to be less backward compatible and maybe less "standard"
Maybe add annotated equivalents tags to "numbered version tag" in the past
Maybe create the future "numbered version tag" as annotated tags
When running using
casadibuild from source using branch currentmain:$ python -c "import casadi;print(casadi.__version__)"output:3.6.3-181-g36d4dd629expected output:3.6.5-6-g36d4dd629As far I understand:
If the current repository node is not a release, state defined by the CMake variable
IS_RELEASEa "+" is apppended "CASADI_VERSION" inCMakeList.txtthis cause the python package to outputCasadiMeta.git_describe()instead ofcasadi.CasadiMeta.version()CasadiMeta.git_describe()store the value ofgit describe --first-parent HEADat time of compilationgit describe --first-parent HEADoutput the last annotated tag (tags with a descriptions) , historically it seems some release tags were annotated ~1/4 were not.git describe --tags --first-parent HEADwill consider also lightweight tags but this would include also tags with formatnightly-*which are not very informative in terms of version numberNot a really problem because:
git describeaccurately identify the state of the repository at time of compilationcasadi.CasadiMeta.version()to check the "release-style" version formatComments:
<some-tag-in-the-past>-<number-of-commits>is not the most intuitive.casadi.__version__from not releases can output something likecasadi.CasadiMeta.version()with$(git rev-parse --short HEAD)appended. I guess the price is to be less backward compatible and maybe less "standard"