You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure if this is a concern for anyone else so I wanted to discuss this before storming off and and creating a pull request ;)
If a config file changes between version 1 and 2 it is quite a pain for the end user to update that file, it means manually transferring every value they changes in the new file.
Usually updates do not change much a option gets added or removed, sometimes something gets renamed.
The simplest idea would be:
have cuttlefish reads the old data ignoring missing options and tossing away unknown ones
write a new config based on the supplied values or defaults from the new schema files
This would probably cover 90% of all cases, it would fail for cases where the type caged but it would give a good starting approach I think.
This could possibly be handled by a simple bash script? Not sure.
A more complex approach would be versioning the config files, allowing to provide versions of the schema files and additional translations form V1 to V2 to V3 etc. This is a lot more complex but would allow for covering every possible aspect.
The text was updated successfully, but these errors were encountered:
This is a rather dirty hack bit it's a start. Basically the way I handle the variables right now is that the 'package' that installs only provides a conf.example and not the actual conf file so I'd call this like:
I am not sure if this is a concern for anyone else so I wanted to discuss this before storming off and and creating a pull request ;)
If a config file changes between version 1 and 2 it is quite a pain for the end user to update that file, it means manually transferring every value they changes in the new file.
Usually updates do not change much a option gets added or removed, sometimes something gets renamed.
The simplest idea would be:
This would probably cover 90% of all cases, it would fail for cases where the type caged but it would give a good starting approach I think.
This could possibly be handled by a simple bash script? Not sure.
A more complex approach would be versioning the config files, allowing to provide versions of the schema files and additional translations form V1 to V2 to V3 etc. This is a lot more complex but would allow for covering every possible aspect.
The text was updated successfully, but these errors were encountered: