3 ms·
Do you mean schema, not data? I've seen three schemes used in production: - single number versioning (V1->V2->V3->V4) - this is the scheme Android's sqlite he
by richardwhiuk 10y ago
Do you mean schema, not data?
I've seen three schemes used in production:
- single number versioning (V1->V2->V3->V4) - this is the scheme Android's sqlite helper insists on https://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html https://developer.android.com/reference/android/database/sql...
- full version numbers, but well defined upgrade tracks enforced in code.
- token based (e.g. a list of upgrades that have been applied)
- vacri 10y agoI've also seen single-number versioning in production that goes '' -> 'v2' -> 'v3' :)
- webmaven 10y agoSchema changes are only one (admittedly, particularly troublesome) type of change that should be versioned. Record changes, additions, and deletions can in many cases be usefully versioned as well. That is, imagine that after a version of the data is released it increases 10X, but the schema doesn't change. That might still be worth making a release for, right? Typically what I see in the wild are data dumps on some sort of semi-regular schedule such as weekly, monthly, or annually, "versioned" with the timestamp or some derivative thereof (eg. "August 2016"). This is much better than nothing, but just as a source dump for each release of an application or other software in a tarball is not as useful as being able to check out a tagged release from a repo, so too versioned data releases that can be checked out with a tag from a repo would be more helpful that a data tarball.