Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete old config/DIP switch files when needed #5

Open
jotego opened this issue Dec 4, 2021 · 5 comments
Open

Delete old config/DIP switch files when needed #5

jotego opened this issue Dec 4, 2021 · 5 comments

Comments

@jotego
Copy link
Member

jotego commented Dec 4, 2021

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.

@theypsilon
Copy link
Member

Very good suggestion. I will put some thought into it and I'll come back to you.

@theypsilon
Copy link
Member

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 ?

@sorgelig
Copy link
Member

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.

@sorgelig
Copy link
Member

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.

@jotego
Copy link
Member Author

jotego commented Dec 30, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants