Versioning of preferences/settings

[Robert Leach]

USE CASE: WHAT DO YOU WANT TO DO?

Add a version to TreeView's preferences so that future versions can handle preference resets/imports automatically.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

n/a

CURRENT BEHAVIOR

TreeView does not know if the preferences/settings file is compatible or not.

EXPECTED BEHAVIOR

TreeView should know the preferences version so that it can gracefully handle incompatibilities.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

Add a preferences/setting version number to the content of the preferences/settings file(s).

FILES AFFECTED (where the changes will be implemented) - developers only

unknown

LEVEL OF EFFORT - developers only

trivial

COMMENTS

[Robert Leach]

Split into issue #406 and #407

[Christopher Keil]

@hepcat72 @lance_parsons Since this has been split into two issues, isn't this just about adding a "key" for the Preferences XML file which denotes the version in a hard-coded way (until we use Gradle and get actual build numbers and can access them through code).

Something like "version=alpha03". This would provide one benefit right now: we can later use this to check whether someone ran alpha03.

If this is all there is to be done, this issue isn't major but trivial. The major part would be the implementation of Gradle building and #407.

[Lance Parsons]

I'd consider the effort trivial, but the priority major. Releasing without this would mean it would be difficult to automatically upgrade users preferences if they used this version...

[Robert Leach]

This isn't a version like "alpha03 (though it could be). The user never has to see this version number. It's embedded in the prefs file and can be an arbitrary number to simply denote when the structure (not the content) of the prefs file has changed. For now, all we need is to insert a place for it and an arbitrary number. We can worry about the code surrounding it in a later release, but without the number there, we won't be able to distinguish this as a previous version different from prior versions.

[Christopher Keil]

Ok yes, that's what I thought. Different versioning than the app makes sense since Preferences could go unchanged. We just gotta make sure we update versions when we change preferences.

[Christopher Keil]

Beginning work

[Christopher Keil]

Added versioning for Preferences API files

In order to distinguish updated versions of Preferences nodes, the Preferences file stored on the system now has a version tag at its root. Routines in ViewFrame.java, where the global configNode is located as a member variable, handle the versions of Preferences and are (bare-bones) set up to deal with version updates.

Resolves: #406 See also: #407

→ <<cset cda402db823b>>

[Christopher Keil]

Added versioning for Preferences API files

In order to distinguish updated versions of Preferences nodes, the Preferences file stored on the system now has a version tag at its root. Routines in ViewFrame.java, where the global configNode is located as a member variable, handle the versions of Preferences and are (bare-bones) set up to deal with version updates.

Resolves: #406 See also: #407

→ <<cset cda402db823b>>

[Robert Leach]

Removing milestone: Settings (automated comment)