3 ms·
Marginally related. I wish I knew the context any more, but I encountered something like this. App keeps updating. Version N understands version N-1's saved
by MarkusWandel 2y ago
Marginally related. I wish I knew the context any more, but I encountered something like this.
App keeps updating. Version N understands version N-1's saved data, maybe N-2, N-3, but not indefinitely. Still you're lulled into a sense of security; your data will always be retrievable. Goes without saying that the app modifies the data store to the latest version.
But then you don't use it for a while and you it's now at N+10 and you still have data from N, and it's slid out of the "backwards compatibility window" and is no longer readable. And the intermediate versions of the App are not available. Now you're screwed. One such scenario, for sure, is updating from version N to, say, N+5 of Android and trying to migrate your data, but I think it was something else.
- rustcleaner 2y agoI thought about this a fair bit, and thought that the way to fix it is to do versioned everything which is an interface to your application or library. What I mean is, as best as one can, one should never break convention and API without including a mechanism to automagic it to how it was before. Making changes which break downstream should be considered the gravest of sins, following at a close second place behind leaving security vulnerabilities unpatched. This is where good abstraction, while expensive to develop, is important: if the abstractions are well-formed then fixing code or adding features should not cause downstream breakage. We always want downstream to focus on using our projects to make cool shit, we don't want downstream spending most of his time fixing his abstractions because we changed ours for the fifth time in seven years. Version 10 should have the figurative similarity matrices to project any version of the format from v1 to v9 into v10 format.