Open jotego opened 2 years ago
Very good suggestion. I will put some thought into it and I'll come back to you.
I think we could add something for cleaning these files to the database format. From the downloader point of view, the only information required would be: 1) the file that needs the maintenance, and 2) a date for each of these files, indicating when the latest breaking change happened. The downloader would know that if the previous run had an earlier date than the breaking change date for a given file, it would have to perform cleanup for that file.
Then, the database maintainers would have to fill that data accordingly. To do that, I think database maintainers will need some extra file in each core repository that would declare breaking changes in the config binary. Some sort of "maintenance.json" file. Thus core maintainers would have to be involved as you suggested. We would need to discuss this solution with the majority of the core maintainers, and come up with a standardized format for that "maintenance.json" file.
My proposal would be adding a file like this to the core repositories:
{
"clear_config:willow.CFG": 1640862137,
"clear_dips:Willow -World-.dip": 1640862137
}
What do you think @jotego ?
To make things simple it's better to delete config/dip if MRA has been changed regardless which part of MRA. Updated should not relay on additional files.
as for config file - it's basically core developer task to care about it. If change may give very bad result then new config should use other bits. If change doesn't affect much then it's not a problem to use same bits.
I agree with @sorgelig in that it is simpler to just delete the DIP switch file upon changes in the MRA.
As for the config file, I do not think that Sorgelig's proposition is practical. It is ideal, but not practical. You can see the list of bits I use here. You can imagine that I try to minimize changes and avoid disruptive ones. But, changes sometimes are unavoidable and will affect hundreds of games. So having some sort of timestamp or git commit hash in a JSON file is a viable method to wash away old config files.
A common source of problems is when the core logic changes leaving the saved config/DIP files unusable and possibly breaking some functionality if used with old files.
For DIP switches, it is easy to detect a change by comparing the dip switch section inside the MRA with the previous MRA file. If a change in the DIP sw. section is detected, the downloader should delete the old file in the
config/dips
folder. This would apply to any MRA of any arcade core.For config file changes, I don't think it's easy to detect automatically because the configuration information shown in the OSD is embedded in the RBF file and has gone through some transformations. So it isn't plain ASCII. Maybe the downloader could read some metadata in the repositories. I could, for instance, make the config string available as plain text in the version.log file of each core. Currently, this file points to the source code git commit used to produce a specific RBF in JTBIN.
Please consider implementing these improvements.