Out-of-date clients cannot create from off-machine configs
Closed this issue · 2 comments
TL;DR: v2.0.0 clients are going to be unable to use config presets following the release of v2.1.0, unless I rebuild the way that remote configs are pulled.
Hi everyone,
I realized as I started preparing this new build that all v2.0.0 clients are going to be unable pull configs from the GitHub during setup due to the fact that I didn't keep separate gmConfig v2 files from the new v3 files. Unfortunately, the project picked up more steam than I was expecting already, and I worry about the implications that removing a massive feature set from almost 200 users. So, I guess, moving forward, I'm really going to have to start thinking about backwards compatibility as well as longevity of out-of-date clients.
Tonight, I'm planning to add automatic update checks and I'll start looking into the best way to keep the config presets lined up with their respective versions. Likely, these updates will make up v2.0.1, and the new features in gmConfig v3 will follow in v2.1.0. If all goes to plan, I could have both updates out tonight, but I want to try and get some more rigorous testing in before then.
Thanks everyone for sticking with me, and I apologize about an issues this may have caused, I'll work to think things through a little more in the future.
Cheers,
TheLittleDoctor
I'm not closing this one yet since I just want to get through this update first, but I made some changes moving forward to the way that remote configs are pulled and I think I got it this time.
Basically, instead of just a single folder, gm_config will now look for a folder which corresponds with the version of gmConfig that the client is on, so in theory, v2.0.0 clients will still be able to find gmConfig v2 files in the same space, and all future versions will be stored in their corresponding folders.
Let's see how this goes.
Everything seems ok for now... I will close the issue for now, but may need to reopen it in the future, maybe. Idk, we'll see.