Currently if we bump the version of a measurement the data for the old version disappears into ether. It's still in the DB, but we lose it from the payload. We should be more intelligent about what happens to old versions. Things to consider: * We could perform one time migration of data from old version to new * We could create new, read-only measurement types representing the old measurements. The data would still show up in the payload. All new data would go to the new version. * We should ensure that values from old or orphaned measurements are eventually pruned from the database.

I'm happy to keep as much of the migration on the server side as is reasonable since we know we will always have to deal with multiple data versions in the server regardless of what the client does after upgrading (because we will have submissions from abandoned installations remaining in the server). I'm leaning toward a solution that would have the client submit a mixture of the old and new data as long as the old data is appropriately tagged with the old version. Then, when we parse on the server side, we just have to pay attention to what version any particular data element has as opposed to the actual age of the document itself. Thoughts? Stuff I'm not considering?

The easiest solution from an "effort involved" perspective is to just "fork" the measurement type for the new version and rip out the data collection code from the old version. If the old measurement version lingers around, complete with its field definitions, its data will be retrieved at payload generation time and that data will be serialized under the old version. All new data will go to the new version since it is the only one with collection code. For measurements that rely on non-longitudinal "last" values (like appInfo), it would be weird to have multiple versions of a measurement reporting in the "last" section. For these fields, we should probably remove them from the old measurement's field definition to avoid double reporting. Unfortunately, it appears that the current DB query code won't filter out "unknown" fields from returned data (it selects all data belonging to a measurement). However, we do avoid the query for "last" fields if there are no fields of that type registered. So, we might luck out in the short term for certain scenarios. Otherwise, we'll need to alter the SQL query to filter on known field IDs or filter the data post query. Not too big of a deal. One aspect we have to keep in mind is provider state. It's stored at the provider, not measurement level. We have to watch out for downgrades here. But, for things like "only write out the app version when it changes" code (which uses provider state), we don't need to worry about extra data being written when we bump the associated measurement version. As far as pruning old data, we're good as-is. The "purge older than 180 days" queries don't distinguish between active and non-active measurements and fields. If data is older than 180 days, it will eventually be deleted. Alternatively, we could pursue writing code that performs data migration. Maybe this would be better than having partial copies of old measurements in the code? But, it does introduce potential for failure and weirdness ensuing from data migration. And we'd have to write code for performing selective deletes. And it would incur a performance hit. I think it's easier and safer to just partially copy measurement definitions. With that in mind, I think we're good to go with bug 837292. We can leave this bug open to prune unknown fields from data in the DB.

I think that with upgrade/downgrade scenarios in play it's probably better to go with per-provider decisions on migration/pruning/inaction. If we find we're revving measurement versions frequently we can revisit a general policy, but I don't expect that to be a big deal. Marking this WONTFIX.