Remove `main_project_versions` in `versions.py`

[kelson42]

Version of libzim, zim-tools, libkiwix, kiwix-tools and kiwix-desktop should be somehow given as argument, not hardcoded in kiwix-build.

[kelson42]

main_project_versions is available at kiwixbuild/versions.py and looks like following:

main_project_versions = {
    "libzim": "9.4.0",
    "libkiwix": "14.1.0",
    "kiwix-tools": "3.8.0",
    "zim-tools": "3.6.0",
    "kiwix-desktop": "2.4.1",
}

It defines for all our c++ projects a version number which is used:

• at github/scripts/common.py to setup EXPORT_FILES which - itself - defines the (binary) files which should be exported in binary packages published by the CD, either nightly builds or releases. See problems around that at Nightly libzim_linux-x86_64-2025-10-25.tar.gz missing libzim.so.9.4.0 #871
• at github/scripts/common.py and .github/scripts/build_release_nightly.py to compute the release/build file names
• at kiwixbuild/dependencies/base.py to AFAIK get the dependency version to build other projects releases against. It is important to notice that in case of a nightly build, anything is always built against a "dev" git main HEAD version of the code.

[kelson42]

• at github/scripts/common.py to setup EXPORT_FILES which defines the (binary) files which should be exported in binary packages published by the CD, either nightly builds or releases. See problems around that at Nightly libzim_linux-x86_64-2025-10-25.tar.gz missing libzim.so.9.4.0 #871

We have decided that we want to have the tooling to build the packages able to clearly identify if something is wrong and for that this piece of Python needs the version number. So if it does not come from the kiwixbuild itself it should be given as argument. Either we give it both for git checkout the code and then to build the package, or we give to checkout the code, and then based on the (checked out) code the Python will decides on which version the code is (from the Meson) and act accordingly. Like for any project this should be easy to achieve once kiwixbuild runs in the target repository as it will be defined in the tag (we do that way for other projects).

• at github/scripts/common.py and .github/scripts/build_release_nightly.py to compute the release/build file names

Here the same, the script building the archives should be give the release version as argument, a thing trivial to do once you run in the repository, following the release event.

• at kiwixbuild/dependencies/base.py to AFAIK get the dependency version to build other projects releases against. It is important to notice that in case of a nightly build, anything is always built against a git main HEAD version of the code.

Here this is different, I'm in favour to treat internal dependencies in the same manner as external dependencies, but there is here a bit of difference:

• Depending what we want to do we want to rely on a released version or on a dev version. I'm in favour to treat the normal case based on a release version (was always my opinion), that will allow stability of the CI (something lacking for the moment, where a change in the libzim can suddently make the CI of the kiwix-desktop failing).
• If we really want to allow easily to build things against dev version (something I might understand), then I would recommend to introduce a new kiwix-build paramter to overwrite the hardcoded dependency. That way we could allow kiwix-build to download from git the latest version and try to compile everything against.

Once important things is that with this proposal with will have to bring the CD to the repositories (so outside kiwix-build repo). Something which should be done anyway... but that implies a bit more of work and probably an adaptation of the kiwix-build GitHub Action.

@veloman-yunkan @rgaudin Does that make sense or is that unclear?