[ckan-dev] Recommended practice for supporting both CKAN 1.8 and 2.0 in extensions

Mon Feb 4 09:22:59 UTC 2013

Hi all,

First of all, thank you very much for all your input. The CKAN devs
had a meetup last week where we discussed the best approach and your
feedback has been very valuable.

The approach that we decided would work best going forward is the following:

*When installing an extension, developers should always use the
"stable" branch, unless there is a specific branch that targets the
CKAN core version they are using.*

Basically, the stable branch will be known to work with the latest
stable CKAN core release, and unless there is a specific branch for
them, with all older versions. For really simple extensions, when
incompatibilities between CKAN versions can be managed with
plugins.toolkit.check_ckan_version(), it may be possible to have
single "stable" branch [1]. For other more complex extensions, we
think we need a model that mimics the one used in CKAN core and allows
us to target specific core versions, but without the need for creating
branches for each new release if that is not needed. That allows also
to maintain and push fixes to separate branches for different CKAN
versions without the extra step of maintaining different repos or
namespaces.
A simplified schema of one of this more complex workflows can be seen in [2].

Of course there is the extra work of maybe cherry-picking fixes to
different branches, but there is no solution that will allow us to
support different versions without having separate branches or
increasing the code complexity.
Having said that, starting from CKAN 2.0 we still aim to make
extensions as compatible as possible between CKAN versions, so if
extensions are indeed compatible, a single "stable" branch could be
enough for all the 2.x line.

We plan to introduce this workflow in the following extensions
supported by the CKAN team (some other may be added as well), and
during the following days we will add this policy to the CKAN docs and
the extensions README.

* ckanext-harvest
* ckanext-spatial
* ckanext-datastorer
* ckanext-archiver
* ckanext-qa
* ckanext-googleanalytics

I hope that all this makes sense. Feel free to ask any further clarification.

Thanks,

Adrià

[1] http://i.imgur.com/YAJ1HgM.png
[2] http://i.imgur.com/xD737UO.png

On 31 January 2013 15:04, Ian Ward <ian at excess.org> wrote:
> On Thu, Jan 31, 2013 at 4:53 AM, David Read
> <david.read at hackneyworkshop.com> wrote:
>> Ian, thanks for expanding on how it might work sharing code across two
>> repositories for an extension. However it seems rather contrived to me
>> and I remain unconvinced by these points. Branches exist for exactly
>> this sort of challenge and seems to me to be the best way for
>> developers to keep track, compare, copy between the two similar
>> threads of work.
>
> I'm in agreement as far as CKAN itself.  The thing we disagree about
> is whether separate repositories should have matching branches.  I've
> made my case and I'll move along now :-)
>
>> Regarding users installing the extensions, I really think we're
>> venturing into cloud cuckoo land if we consider the jump from 1.x to
>> 2.0 as the only compatibility jump we're going to see. I've managed
>> most of the CKAN releases from 1.2 when extensions were introduced,
>> and every release there has been at least one extension that needed
>> updates due to changes in interfaces. So we need to have a system of
>> branching and referencing compatibility, whatever.
>
> This is the important point.  ckanext2 namespace or no, the decision
> is what to do when loading an extension against a particular CKAN
> version.
>
> I see plugins.toolkit.check_ckan_version() allows testing for a range
> of CKAN versions.  So, if I want to support CKAN 1.8 and 2.x from the
> same code base, I can just add that check to the parts of my code that
> needs it.  That's good enough for me.
>
> Looking more closely it seems there is nothing special about the
> ckanext namespace package.  I could put my extension code wherever I
> want if I set up the right setuptools entry points, right?
>
> Ian
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev

On 31 January 2013 15:04, Ian Ward <ian at excess.org> wrote:
> On Thu, Jan 31, 2013 at 4:53 AM, David Read
> <david.read at hackneyworkshop.com> wrote:
>> Ian, thanks for expanding on how it might work sharing code across two
>> repositories for an extension. However it seems rather contrived to me
>> and I remain unconvinced by these points. Branches exist for exactly
>> this sort of challenge and seems to me to be the best way for
>> developers to keep track, compare, copy between the two similar
>> threads of work.
>
> I'm in agreement as far as CKAN itself.  The thing we disagree about
> is whether separate repositories should have matching branches.  I've
> made my case and I'll move along now :-)
>
>> Regarding users installing the extensions, I really think we're
>> venturing into cloud cuckoo land if we consider the jump from 1.x to
>> 2.0 as the only compatibility jump we're going to see. I've managed
>> most of the CKAN releases from 1.2 when extensions were introduced,
>> and every release there has been at least one extension that needed
>> updates due to changes in interfaces. So we need to have a system of
>> branching and referencing compatibility, whatever.
>
> This is the important point.  ckanext2 namespace or no, the decision
> is what to do when loading an extension against a particular CKAN
> version.
>
> I see plugins.toolkit.check_ckan_version() allows testing for a range
> of CKAN versions.  So, if I want to support CKAN 1.8 and 2.x from the
> same code base, I can just add that check to the parts of my code that
> needs it.  That's good enough for me.
>
> Looking more closely it seems there is nothing special about the
> ckanext namespace package.  I could put my extension code wherever I
> want if I set up the right setuptools entry points, right?
>
> Ian
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev