Proposal: versioning for model*.ini-files

I thought about how to add more functionality to deviation (more switches, more hardware like vibration motor, more items on the big Devo12 screen, virtual switches) and I regularly feel limited by considerations about backwards compatibility.
It is quite difficult to bring the goal "keep compatibility" and developing new features together. With the toggle icons we found a way to make it compatible with elder versions but in many other cases I can not find such a way ( example: more boxes on the Devo12 gui ).

So I tried to code a simple versioning flag (fileversion) to the model config. It is quite easy - only an additional parameter=value pair in the model*.ini (could be used also in the tx.ini for tx-specific addons).

My idea is to define the actual (2.1.1) model config as version 0. For a future version (simply count up the fileversion-value) the code can read the fileversion-parameter (and set it to the highest in the code supported value if unknown). With some if / switch clauses we could quite easily sort out which addons are available.
If an addon requires additional values in the model config file we can put them in special sections like [version1], [version2]... We have no structure (sections) inside such a [version*]-section, but it seems to be the easiest way to prevent mixup between standard config parameters and the addons without need to recode the parser (CONFIG_ReadModel / ini_handler functions in config/model.c) so that the plausibility checks will not be disturbed by possible extensions (esp. don't expect numbers to consist of only one digit).
This completely eliminates the need to use additional files, to use parameters which are not understood by some code versions and provides an easy and clear way for addons. We can put information about the addons in a (existing model.h or new) header file what would make tracking addons easy.

I think this is one of the central points for the further development of deviation (PhracturedBlue, forgive me if I am completely wrong from your point of view and explain it to me). Everywhere we try some enhancements which leave the well known path we were stopped by this limitation.

FDR wrote: Actually there are cases, like the one in the example (the more boxes), when the lesser DEVOs could just ignore the unsupported options, i.e. use only the first 8 boxes on their main page...

Yes, but using "box12" will overwrite now the settings for "box1" (this is what I meant with the plausibility checks - they would have to be improved for this).

However, adding new settings to the core, for example into the mixer structure, cannot be done nicely with additional [version1], [version2] sections.

Agreed. But the old section's config values could be overwritten (while parsing) by the new section (so we have the old section for elder versions and the addon section which can be an addon or a substitution for the old section). We would have to make sure that the old section contains values which do not hurt (e.g. from a template if they can not be extracted from the new values).
And maybe we can use other names like [ultimate mixer] instead of [version 12] - more a cosmetic issue when having a little help from translation code.

Furthermore, a model config which configured to use all the additional controls of the DEVO 12 won't be useful on the other transmitters whether you have a version in it or not, so the compatibility will be limited anyway...

Again, an intelligent algorithm to extract the values for elder versions or the use of a standardized template would at least make sure, that the config read by elder versions will not hurt material or persons...

Looks good, I must look into the code to see what happens but I run out of time for now.

I only wanted to mention that the CONFIG_WriteModel only writes the parts of the ini file it has stored internally as model attributes. Everything else will be lost when opening and saving a model file with a former version if we implement it like I described above.
Maybe we have to copy the sections from the original file to the new written version or it is a good idea to throw it away for avoiding incompatible settings - I do not know what is better. I'll think about this later...

I posted a longer text in another thread, maybe wuold have been here better.
Please read also this text .