Right now the version stored on the server contains the latest weave version to talk to the server. We could store a storage version so that multiple weave versions can talk to each other instead of requiring every client to update.

This is basically backing out the latest versioning change: http://hg.mozilla.org/labs/weave/rev/9f7b464c9199

Comment on attachment 431443 [details] [diff] [review] v1 >+storage_version := 1.2pre1.1 I know this is tricky, but can we commit to (i.e. document and write tests for our impl) and specify an all-numeric versioning scheme, preferably something that doesn't depend on our version comparator impl? This should not tie to release versions, IMO, and I'd even say it should just be ints, since we're now not planning on doing minor revs of versions

(In reply to comment #2) > >+storage_version := 1.2pre1.1 I added the extra .1 so that I can bump it in the blocked bug/patches, but yes, we can untie this from the client versioning too. Should it just be 1 when we finally release? Start with 0.1 for this bug and bump up to 0.8 and before shipping, bump to 1 with bug 549635?

Oh and one caveat is that we'll need to rename storage version in meta/global because previous clients are comparing against it. Alternatively, we can just start at 2 instead of 1.

Let's just start at 2. It's just an int.

Do we want to fix this here or bump it from 1.2pre.8 up to 2 in bug 549635? Keeping it a value less than 2 lets us add more storage changes if something comes up during testing of dev snapshots.

Switch to a plain int, 2, for storage version and remove Svc.Version usage.

Comment on attachment 431730 [details] [diff] [review] v2 > if (!meta || !meta.payload.storageVersion || !meta.payload.syncID || >- Svc.Version.compare(COMPATIBLE_VERSION, remoteVersion) > 0) { >+ STORAGE_VERSION > parseFloat(remoteVersion)) { please add a comment here explaining why we need parseFloat r=me, requesting system-review from mhanson

The (old, removed) comment for COMPATIBLE_VERSION indicates "If the server contains an older version, this client will wipe the data on the server first." That's a useful bit of information for future coders, let's leave it in. Also, let's make sure we change the developer documentation part of the wiki, to preserve the version 1 object doc, create a version 2 object doc, and table that describes which versions went into effect when (with time and addon version #s). Otherwise sr+.

Hanson already sr+ in comment 9 but just didn't mark the patch.

We'll want a page similar to https://wiki.mozilla.org/Labs/Weave/Developer/BrowserObjects except for.. "StorageObjects" ? I guess for now I can put all versions on the same page. This page would describe all structures outside of a data payload: meta/global, crypto, keys, data crypto, client data for v1.

http://hg.mozilla.org/labs/weave/rev/b471bb26e9ef Move back to a model where multiple client versions can read the same data of the same storageVersion. The only time meta/global is written is on a freshStart/server wipe. Initialize the version to 1.2pre1.1 so that individual storage-incompatible changes can bump the value. Old versions are strings, so estimate with a parseFloat, but future versions will be integers.

I've documented the original storage format and the current version (2) as well as the changes between the versions: https://wiki.mozilla.org/Labs/Weave/Developer/StorageFormat