On 29.05.2025 17:42, ichthyo wrote:
- implement a more fine-grained compatibility logic.
See Config::is_compatible(VerInfo)
* only revision differs => compatible
* other version is newer => incompatible
* both have same major: silently accept any lower minor
* when current-Yoshimi is a major-bump: accept 1 major back
On 30.05.25 11:06, Kristian Amlie wrote:
One question: What do you mean exactly with "accept 1 major back"? Accept
silently? Or accept, but warn?
The reason I ask is that if we bump the major version, it is likely
because we introduce some kind of incompatibility.
you spotted quite well that I waver between two attitudes towards this problem.
On the one hand, we have rather elaborate code in the code base to check
versions and give an compatibility warning. Yet on the other hand, when it
comes to actually loading old data, we apply the policy to silently load,
possibly convert (or fall back to defaults) as we go. This, of course,
is complemented by a generally conservative approach to our data storage;
we tend to stick to existing structures as good as we can.
On 30.05.25 19:01, Will Godfrey wrote:
I don't think there is any need to make any special arrangements for older
config files, except to advise the user that it is an older one and that
they should check the settings. If they then change a setting that
will itself resave the entire file.
The only file type that is critical is the Instrument one. For all the others,
losing one would be inconvenient but not disasterous. Yet currently we don't
even mark Instrument files as changed let along recommending saving them!
...and with the clause to silently accept all minor revisions from the previous
major when we do a major-bump (as from 2.x to 3.0), I kind of tried to sweep
this problem under the carpet, assuming that actually we *do not want* to
break anything, either related to config or to instruments. Why then warn
everyone of problems we actually try quite hard to avoid altogether?
So the warning should rather be reserved only for boundary cases, like
porting a 1.x config to a 3.x Yoshimi, or for cases of forward-compatibility
(opening newer config with an older version of Yoshimi)
On 30.05.25 11:06, Kristian Amlie wrote:
I'm somewhat skeptical of automatically resaving in general. If the config
is compatible enough not to require any warnings, then resaving is
unnecessary, since loading it again later will produce the same results.
This is a good observation ....
As said, I am not not sure what would be the best course of action
- not saving, just warning. Then possible problems (things we developers
overlooked) might materialise later, and might go unnoticed by the user
- saving and warning, which would perform any implicit config migration
- should we just always warn when the config version differs?
- should we re-save on every minor bump? (as we did up to now)?
- or should we stick to the current idea to warn only on exceptional cases
and only re-save in those cases (as it is implemented on my branch)?
-- Hermann
PS:
On 30.05.25 10:30, Will Godfrey wrote:
> I suggest we simply change Line 118 in Config.cpp to:
> const VerInfo Config::VER_ZYN_COMPAT{2,4,3};
will change that on next occasion
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
