[ckan-discuss] initial considerations for distribution of CKAN model changes

John Bywater john.bywater at appropriatesoftware.net
Mon Feb 22 20:10:25 GMT 2010


John Bywater wrote:
> David Read wrote:
>> There's the issue about ckan instances talking to each other that are
>> at different software versions. So maybe a concept of an API version?
> 
> Yes. I think this should mostly become part of the REST API (which would 
> simply present the changeset patch model, and possibly the changeset 
> publish-subscribe model if we get that far). So perhaps the REST API is 
> already versioned? If not, capabilities detection would probably work 
> for backwards compatibility.
> 
> But if we can get this "right first time" (like Mercurial) I'm sure it 
> would help....

Actually, beyond the version of the API, I'm sure it would be important 
to think carefully about how updates between different model versions 
could work. We wouldn't want to require co-operating CKAN instances to 
do synchronized software upgrades. :-)

So we may wish to provide a fringe of backwards and forwards 
compatibility (of perhaps 3-12 months of previous system revisions - it 
depends on how quickly you require others to upgrade their systems 
before they become isolated from the most up-to-date services).

The mechanisms for creating patches, for detecting conflicts, and for 
applying patches could do the hard work:

If the update is from an earlier version to a more recent version, the 
newer version may know how to apply patches from older system. Going the 
other way, the older version couldn't possibly know how to apply 
correctly patches from a newer version. So perhaps the newer version 
could instead provide to the older version the kinds of patches that it 
can accept? When the older system is later upgraded, it may have some 
catching up to do, but changeset patches could be marked as "retarded" 
so a system knows what to catch up on - that might not take so long if 
upgrades are reasonably prompt. (Warning notifications could be issued 
to admins if sites start receiving retarded patches?)

If the model schemas are too different (ie the differences aren't 
supported), it may be that received patches are considered to conflict, 
and resolution involves upgrading the system?

So there appears to be a choice: either the patch is applied and 
information lost (or perhaps delayed) or the patch remains queued and 
divergence starts to increase (risking generation of more conflicts to 
be resolved after the older version is levelled up).

So, ideally, there would either be zero data model changes, or services 
would perform synchronized software upgrades. :-) Of course, it won't 
happen like that. But I guess long term, if this becomes popular, 
regular software system releases would really help others' plan to keep 
their services up-to-date (and therefore running smoothly).

J.




More information about the ckan-discuss mailing list