<neobrain> fwiw also it's not worth even attempting to try to do any kind of cross-version compatibility - dolphin did that for other stuff with much smaller scope and still regularly broke the versioning
<neobrain> (referring to any approaches that require manual versioning, anyway)
<jroweboy__> no it wouldn't be like ignoring a service in the older state, but say we find out that 90% of games work with the initial implementation, but some games don't because we aren't serailizing some specific field, i'm suggesting that we don't need to invalidate all the previous save states when it only affects a small number of games but
<jroweboy__> if what neobrain says is the case then this is probably a bad idea :)
<neobrain> yeah, it's just one of those things that sound convenient to have for end users but ultimately is just going to cause lots of frustration for them because things never would work quite right
<neobrain> at the end of the day users shouldn't rely on snapshots heavily enough for the lack of cross-version compatibility to become a blocker for updating anyway
<jroweboy__> neobrain: one thing you mentioned was manual versioning. are you hinting that a scheme involving some generated version number from the serialized fields is a better approach? (kinda like java default serialversionUID ?)
Subv - 12/21/2017
we also have no idea how savestates will interact with actual sd/nand saves (probably badly)
CitraBotBOT - 12/21/2017
<neobrain> jroweboy__: yes, I call this scheme "snapshot version = git hash of current citra build"
<neobrain> doesn't quite roll off the tongue too well yet
<jroweboy__> heh. i remember suggesting that for multiplayer versioning as well :)
<neobrain> More seriously though, any version number generated solely from state fields is prone to fail because it doesn't consider the version-specific details of how those fields are used. The parameters described by a snapshot generated in one build may be an outright invalid configuration on another build
<neobrain> That particular point may be manageable, but then take a look at the documentation Citra's code base has currently and ask yourself again whether such management is a maintainable longterm solution :p
CitraBotBOT - 12/21/2017
<Lioncash> I will cry if we have to maintain boilerplate around save-state code because of version numbering and not wanting to break save states (imo save states should complement the in-game saving, not be the catch-all)