I am not sure how relevant this is in Jo's mobile scenario.
Not very similar, but nevertheless relevant to get an idea of the scope we are targeting.
For mobile (and probably also other integration and "light client" use cases) we generally need versioning for reasons like
1) not working on the full dhis "metadata set" on the other side (so versioning by "database upgrade" is not an option),
2) limited bandwith (and storage, the nature of the clients) means that we want to limit what we have to send to the client to a minimum, and
3) the sheer number of "uncontrolled" clients means that we cannot really rely on controlled, manual client upgrading (if we can avoid it).
PS. That said I am not sure how appropriate the versioning paradigm is in this scenario. What if you want to change the name or add an element in the national database, should we then deny all out-of-date districts to report any data at all? Can we live well with what is described above?
That's one of the reasons I would like to have a bit more high level discussion about versioning before going further. But I don't really think this example is a good way of framing it. There is really nothing that says that fixing a typo in a name has to represent a new version, or that versions cannot be marked in different ways (such as "extending" or "cosmetic"). There is also nothing that says you have to throw the data away because you have versioning, versioning can actually help you do the opposite 
So to me it is more a case of, as Bob said, *how* we want versioning to be done rather that if.. And I'm pretty sure we'll find more and more use cases where versioning globally will not be enough, as we go along..
I'm adding an example of how mobile versioning might be implemented in a "manual" fashion (it has not really been worked through, though). For mobile we "cosmetic" fixes that are important to notify to the client (ordering, section changes, names) but would not mean incompatible changes to the data values being edited or sent. It might be that these differences between compatible and incompatible changes are more general? (This will probably only be an option where decent gprs is realtively available and stable, btw)
Server side configuration:
- We make a serverside management page that lists all data sets with an option to "publish" them for mobile reporting
- published datasets can be manually tagged as "extended", "incompatible change" or "removed"
- when saving this configuration, we timestamp (version) all changes made, and also save a timestamp/version for the mobile set as a whole.
(Extended might be tricky, depending on how complex it is to change how the client works, might only be a "texts changed" flag for now. Ideally it would mean that the client is capable of reorganizing stored dataValueSets on the phone to allow for changes to the order of element and sections and also added elements in the form that is not present in the stored datavaluesets.)
Client side updating:
- When downloading forms, we send the forms published in this console, adding the the timestamps to datasets downloaded (and also the timestamp for the whole set)
- When starting the app on the mobile, we try to make a request to the server for changes (if it fails, ignore it).
- if something has changed, we download the changes
- if change is extended, or removed, no problem
- if change is incompatible, remove the dataset and any locally saved data (warning the user in that case)
Sever side "report" recieving:
- data recieved from client will be checked against the current version
- if it's the same version or there is not an incompatible change between the versions -> store
- if there is an incompatible change store in a queue for admin evaluation (much like is implemented for sms now)
....
Jo
···
Den 9. des. 2010 kl. 23.55 skrev Lars Helge Øverland: