[ckan-discuss] initial considerations for distribution of CKAN model changes
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).
More information about the ckan-discuss