@haugstrup: I’ve been thinking about that issue as well, but the alternative to having group ID changes would be not being able to provide any linkable identifiers for the vast majority of games (and there would probably still be some group changes going on anyway).
Considering the two reasons why a group change might occur, I actually don’t think this is a huge issue:
1.) The machine has not been grouped yet: In this case, you’re out of luck anyway, but using the actual IPDB ID for linking purposes might still work. I’m going to add the timestamp of the last group change to each machine, and if it’s 0, you can consider the group ID not final and ignore it, if you want to persist group IDs and not hit up the API every time.
2.) There has been a mistake:
a) I missed a machine that has a lower ID than all the others of its group. Unlikely, but in that case, I’ll keep the established group ID. As for the one I’ve missed, you’re going to have to do an update anyway.
b) Some established group membership turns out to be wrong, e.g. we bunch together GoT and GoT LE, and upon seeing tournament footage we realize that’s not right. There’s nothing that can be done about that, the group ID has to be updated.
c) I dun goofed. If there’s any stupid mistake on my part, the group IDs will have to be updated no matter what.
To mitigate the impact of group changes for people not wanting to hit up the API every time, the timestamps I mentioned might help, but I could also see a subscription model working – I’ll keep the API URLs of applications wanting to get notified of group changes and tell them every time a change occurs, so there won’t be any limbo links until their cache expires. I think, all in all, this would work better than never changing group IDs, which I’m afraid I can’t guarantee anyway.
@romballs: We had a bit of a collision there, I answered by email just as you replied here. My reply may have been a bit wordy – @haugstrup said it just as well, and way more succinctly.