chinwag/chinwag-android
chinwag/chinwag-android
2
0
Fork 0
Code Issues Pull requests Releases 5 Activity

Use an explicit SCHEMA_VERSION instead of BuildConfig.VERSION_CODE (#3324)

Browse source 
* Use an explicit SCHEMA_VERSION instead of BuildConfig.VERSION_CODE

Every nightly release has a new BuildConfig.VERSION_CODE, so the previous
code would not do the right thing.

Require the schema version to be explicitly set. While I'm here, provide
a clear set of guidelines as to what has to happen when the schema changes.

* Improve documentation links
This commit is contained in:
Nik Clayton 2023-02-25 21:22:49 +01:00 • committed by GitHub
commit fda8c80949
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 36 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

31
app/src/main/java/com/keylesspalace/tusky/settings/SettingsConstants.kt
View file

@ -12,6 +12,37 @@ enum class AppTheme(val value: String) {
}
}
/**
* Current preferences schema version. Format is 4-digit year + 2 digit month (zero padded) + 2
* digit day (zero padded) + 2 digit counter (zero padded).
*
* If you make an incompatible change to the preferences schema you must:
*
* - Update this value
* - Update the code in
* [TuskyApplication.upgradeSharedPreferences][com.keylesspalace.tusky.TuskyApplication.upgradeSharedPreferences]
* to migrate from the old schema version to the new schema version.
*
* An incompatible change is:
*
* - Deleting a preference. The migration should delete the old preference.
* - Changing a preference's default value (e.g., from true to false, or from one enum value to
* another). The migration should check to see if the user had set an explicit value for
* that preference ([SharedPreferences.contains][android.content.SharedPreferences.contains]);
* if they hadn't then the migration should set the *old* default value as the preference's
* value, so the app behaviour does not unexpectedly change.
* - Changing a preference's type (e.g,. from a boolean to an enum). If you do this you may want
* to give the preference a different name, but you still need to migrate the user's previous
* preference value to the new preference.
* - Renaming a preference key. The migration should copy the user's previous value for the
* preference under the old key to the value for the new, and delete the old preference.
*
* A compatible change is:
*
* - Adding a new preference that does not change the interpretation of an existing preference
*/
const val SCHEMA_VERSION = 2023021501
object PrefKeys {
// Note: not all of these keys are actually used as SharedPreferences keys but we must give
// each preference a key for it to work.