program_version in snapshot metadata stuck at 0.9.0 despite CLI being 0.10.3

[543069760]

Describe the bug
There is a version mismatch between the CLI output and the metadata saved in snapshots. When running ./rustic -V, it correctly reports rustic 0.10.3. However, when a backup is performed, the resulting snapshot metadata (JSON) records program_version as rustic 0.9.0.

To Reproduce
Build rustic from the v0.10.3 branch.

Verify CLI version: ./rustic -V -> Output: rustic 0.10.3.

Perform a backup: ./rustic -r backup .

Check snapshot metadata: ./rustic -r snapshots --json.

Actual Result in JSON: "program_version": "rustic 0.9.0"

Expected Result in JSON: "program_version": "rustic 0.10.3"

Technical Details
I am working on a fork that introduces SQL mode and Android NDK support:

Fork Branch: 543069760/rustic-sql (v0.10.3-branch)

Action Run: Run #21696060591

It seems the snapshot creation logic is pulling the version from rustic_core (which is indeed at 0.9.0 in Cargo.toml) rather than the CLI's package version.

Ini, TOML

Main Cargo.toml

[package]
name = "rustic-rs"
version = "0.10.3"

[dependencies]
rustic_core = { version = "0.9.0", ... } # This seems to be the source of the issue
Question
Should the program_version in snapshots reflect the CLI version or the core library version? If it's intended to be the CLI version, could you point out where the snapshot header is constructed so I can submit a PR to fix this decoupling?

Test：
[root@localhost rustic]# OPENDAL_BUCKET="XXXXXXXXXXXX" OPENDAL_ROOT="/777/" OPENDAL_ENDPOINT="https://XXXXXXXXXXXXXXXXX" OPENDAL_SECRET_ID="XXXXXXXXXXXXXXXXXX" OPENDAL_SECRET_KEY="XXXXXXXXXXXXXXXXXXX" RUSTIC_PASSWORD="XXXXXXXXXXXXXXXX" ./rustic -r opendal:XXX backup /root/tempdir -r opendal:cos --progress-interval 1s
[INFO] using config ./rustic.toml
[INFO] repository opendal:XXXXXXXXXXXXX: password is correct.
[INFO] using cache at /root/.cache/rustic/76c3d249f1e506ff48ffcd472c1314c4814a9bb42823901f9ac4df5da52283d5
[00:00:00] reading index...               ████████████████████████████████████████        159/159                                        
[00:00:00] getting latest snapshot...     ████████████████████████████████████████        153/153                                        [INFO] using parent 280cae55
[INFO] starting to backup /root/tempdir ...
[00:00:00] backing up...                  ████████████████████████████████████████  30.14 MiB/30.14 MiB  31.90 MiB/s  (ETA -)            [INFO] Files:       1 new, 0 changed, 2 unchanged
[INFO] Dirs:        0 new, 3 changed, 0 unchanged
[INFO] Added to the repo: 9.2 MiB (raw: 9.2 MiB)
[INFO] processed 3 files, 30.1 MiB
[INFO] snapshot 581b3081 successfully saved.
[INFO] backup of /root/tempdir done.
[root@localhost rustic]# ./rustic -V
rustic 0.10.3
[root@localhost rustic]# OPENDAL_BUCKET="XXXXXXXXXXXXXX" OPENDAL_ROOT="/777/" OPENDAL_ENDPOINT="https://XXXXXXXXXXXXXX" OPENDAL_SECRET_ID="XXXXXXXXXXXXXXXX" OPENDAL_SECRET_KEY="XXXXXXXXXXXXX" RUSTIC_PASSWORD="XXXXXXXXXXXXXX" ./rustic -r opendal:XXX snapshots --json --filter-last 1
[INFO] using config ./rustic.toml
[INFO] repository opendal:XXXXXXXXXXXXXXXX: password is correct.
 {
    "group_key": {
      "hostname": "localhost.localdomain",
      "label": "",
      "paths": [
        "/root/tempdir"
      ]
    },
    "snapshots": [
      {
        "time": "2026-02-05T10:29:30.211673358+08:00",
        "program_version": "rustic 0.9.0",
        "parent": "280cae559017f9392facd7d9d5ea5972e5e03ef107057d249b571e44edaa429b",
        "tree": "62696ccb87a38b29b3baf84545817a312e9a65a4aa0889960b47537976292c32",
        "paths": [
          "/root/tempdir"
        ],
        "hostname": "localhost.localdomain",
        "username": "",
        "uid": 0,
        "gid": 0,
        "tags": [],
        "original": "581b3081d1d639bf51145a9ba5e324656519cec71980c2b830c5651b1f1497b7",
        "summary": {
          "files_new": 1,
          "files_changed": 0,
          "files_unmodified": 2,
          "total_files_processed": 3,
          "total_bytes_processed": 31609315,
          "dirs_new": 0,
          "dirs_changed": 3,
          "dirs_unmodified": 0,
          "total_dirs_processed": 3,
          "total_dirsize_processed": 3301,
          "data_blobs": 10,
          "tree_blobs": 3,
          "data_added": 9656841,
          "data_added_packed": 9646329,
          "data_added_files": 9653540,
          "data_added_files_packed": 9644519,
          "data_added_trees": 3301,
          "data_added_trees_packed": 1810,
          "command": "./rustic -r opendal:XXXXXXX backup /root/tempdir -r opendal:cos --progress-interval 1s",
          "backup_start": "2026-02-05T10:29:30.311577977+08:00",
          "backup_end": "2026-02-05T10:29:31.171718300+08:00",
          "backup_duration": 0.860140323,
          "total_duration": 0.960044942
        },
        "id": "581b3081d1d639bf51145a9ba5e324656519cec71980c2b830c5651b1f1497b7"
      }
    ]

[543069760]

https://github.com/rustic-rs/rustic/blob/v0.10.3/src/commands/backup.rs#L367

let snap = hooks.use_with(|| -> Result<_> { let source = source .clone() .sanitize() .with_context(|| format!("error sanitizing source=s\"{:?}\"", source))? .merge(); Ok(repo.backup(&backup_opts, &source, self.snap_opts.to_snapshot()?)?) })?;

I’ve been digging into the source code to understand why the versioning behaves this way. In src/commands/backup.rs, the backup_snapshot function utilizes the following logic:

It calls repo.backup(...), which is an interface provided by the rustic_core library.

It passes the result of self.snap_opts.to_snapshot()? to provide the snapshot metadata.

My Analysis: It appears that when rustic_core executes the backup and generates the SnapshotFile, it checks the program_version field. If this field is empty, it defaults to the CARGO_PKG_VERSION of the crate being compiled—which, in this case, is rustic_core itself (v0.9.0).

Since the main CLI (rustic-rs) is at v0.10.3 but depends on rustic_core v0.9.0, the metadata ends up recording the library version instead of the user-facing CLI version.

Questions for the developers:

Is this "version decoupling" between the CLI and the Core library intended for snapshot metadata?

Should the CLI explicitly inject its own version string into the SnapshotOptions before calling repo.backup() to ensure the metadata reflects the actual tool used?

If I were to submit a PR to force the CLI's version into the snapshot metadata, would that align with the project's architectural goals?

[aawsome]

Hi @543069760!

The program_version is evaluated during the build from the env variable PROJECT_VERSION.

In rustic there is a build.sh which is used in the CI builds and has the following content

PROJECT_VERSION=$(git describe --tags) cargo build -r $@

This is a bit of a hacky solution; you can submit a PR to improve this and we'll happily discuss it and merge when it's ready.