[chore]: avoid manually syncing cloudinit/version.py __VERSION__ string during release. Base value in meson on upstream annotated tags

[blackboxsw]

Taken as a carryover work item from #6326.

Upstream would like to avoid having to sync static string values based on upstream annotated tags. Now that we use meson as our build backend, we should be able to use https://mesonbuild.com/Reference-manual_functions.html#vcs_tag to render cloudinit/version.py::__VERSION__ value from the latest annotated tag matching a specific regex.

Considerations that need to be taken into account:

• hotfix branches 25.2.x will have annotated tags which don't make it into main
• main devel branch will continue to carry a git describe value of a previous major.minor release , do we want that to actually be incremented to 25.3-devel or something?
• other downstream repos may have different annotated tag policies, how do we avoid breaking those downstreams
• some downstreams may try building from release tarball which will not contain .git revision info, how will meson accommodate those downstreams

[mostafaCamel]

I may work on this issue in 2 or 3 weeks. For now , just scribbling my notes:

• For the hotfixes and the OSrelease-specific tags, we can have a regex to only isolate the first \d+\.\d+ in the tag name

• There still to be many references (you need to be logged in to github in order to view the search results in the code) of the function version_string() . Example

• So whatever changes we make will probably need to be inside this function or for the build system (meson) to generate some sort of artifact (environment variable or a config file) that version_string() will read

• We will probably also need in version.py a fallback to a dummy value in order to keep running unit tests and quick-and-dirty testing/development decoupled from the build system

• For the issue of breaking downstream repos with different tag policies, maybe we can keep setting the fallback values as the real version for a few months while we advertise that at date X, we will stop the manual setting and they need to figure out how to set their forked cloud-init's version

  • Their fix may be as simple as running git describe --exact-match <commit sha> on the cloud-init commit they are rebasing from
  • For the tarballs, they can use git get-tar-commit-id