backward compatibility / breaking changes

[GuitarBilly]

Please bear with me... (see edit)

Playing around with (or trying to break 8-) npbackup I noticed that npbackup v3 cannot open nor check v2 config anymore. And with such big changes that is fine.

~$ npbackup.v3.0.0-rc14/npbackup-gui/npbackup-gui -c npbackup/npbackup.conf.2.2.1-P7-x64.2023082801.bak
2025-02-23 18:14:25,681 :: INFO :: GUI: npbackup 3.0.0-rc14-linux-gui-x64-public-3.12-c 2025021401 - Copyright (C) 2022-2025 NetInvent running as linux
2025-02-23 18:14:25,692 :: CRITICAL :: Cannot read conf version from config file /home/linux/npbackup/npbackup.conf.2.2.1-P7-x64.2023082801.bak, which seems bogus
2025-02-23 18:14:25,692 :: INFO :: Using configuration file /home/linux/npbackup/npbackup.conf.2.2.1-P7-x64.2023082801.bak

~$ npbackup.v3.0.0-rc14/npbackup-cli/npbackup-cli -c npbackup/npbackup.conf.2.2.1-P7-x64.2023082801 --check-config-file
2025-02-23 18:07:05,431 :: INFO :: npbackup 3.0.0-rc14-linux-cli-x64-public-3.12-c 2025021401 - Copyright (C) 2022-2025 NetInvent running as linux
2025-02-23 18:07:05,440 :: CRITICAL :: Cannot read conf version from config file /home/linux/npbackup/npbackup.conf.2.2.1-P7-x64.2023082801, which seems bogus
2025-02-23 18:07:05,440 :: CRITICAL :: Cannot obtain repo config
2025-02-23 18:07:05,446 :: INFO :: ExecTime = 0:00:00.016843, finished, state is: critical.

However, going forward in the future it would be good to have some kind of version/generation indicator in the config file?
This way the user can be more gracefully alerted that this is a valid npbackup config but should be opened with an older existing version. Instead of the above "something is critically wrong, good luck in figuring it out and opening you precious backups" message...
Also npbackup could determine if it can 'upgrade' the config if smaller non-breaking items are being added. So it would serve forward and backward compatibility items.

EDIT: and only now I check the newer config file format and see it already has conf_version indicator. Well done! Hopefully with also this scenario in mind.

~$ head npbackup/npbackup.conf.3.0.0-rc15
conf_version: 3.0
audience: public
repos:
  default:
    repo_uri: 

for comparison here the old version config style

~$ head npbackup/npbackup.conf.2.2.1-P7-x64.2023082801.bak 
backup:
  compression: auto
  use_fs_snapshot: false
  ignore_cloud_files: false
  exclude_caches: true
  exclude_case_ignore: false
  one_file_system: true
  priority: low

[deajan]

Indeed, I already have fixed minimum and maximum conf version constants in the program, to handle proper error messages in future like
"ohh, your conf v3 version is too old, and can be updated automatically" or "you'll need to manually update your config to newer version".

But since v2 config files didn't have that value, it's difficult to have an accurate error message, since the same value would be missing anyway
if you open any kind of yaml file.

Unless something groundbreaking happens, v3 should always be able to read elder config files, while using an elder program with newer config files will work in CLI, and complain that there are unknown entries in GUI.
v3.1 will also have a new email tab for monitoring (I myself won't use it, but people have asked for this, because it's easier to setup than prometheus, even if it's not as reliable).
v3.2 will probably have a KVM/Qemu tab to enable backing up virtual machines, which as of today need an external script.
Those changes should be backwards compatible.

Again (and again), thanks for the help you provide, really appreciated.