[ckan-discuss] IMPORTANT: How we will handle different CKAN versions from extensions

Mon May 13 19:27:51 BST 2013

Hi all,

Now that CKAN 2.0 is finally out we will start implementing the policy
we agreed a while ago to handle how extensions keep compatibility with
different CKAN versions.

The full details are on the message below, but the gist of it is:

*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.*

The main impact of this will be that if you were using eg
ckanext-spatial or ckanex-harvest you will probably need to switch
branches:

* If you are targeting CKAN 1.8, you were using "master" and will need
to switch to "release-v1.8"
* If you are targeting CKAN 2.0, you were using "release-v2.0" and
will need to switch to "stable"
* If you are targeting CKAN master, you will need to use "master"

We will keep the release-v2.0 branches on the different extensions for
a while to ease the migration, but ideally these will be removed
eventually to avoid confusion (until backwards incompatible changes
are introduced to the extension and we need to create them again)

The process will take place in the coming days starting tomorrow and
it will affect the following extensions:

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

Let us know if you have any doubts regarding this.

Adrià

Full discussion thread:
http://lists.okfn.org/pipermail/ckan-dev/2013-January/003737.html

---------- Forwarded message ----------
From: Adrià Mercader <adria.mercader at okfn.org>
Date: 4 February 2013 09:22
Subject: Re: [ckan-dev] Recommended practice for supporting both CKAN
1.8 and 2.0 in extensions
To: CKAN Development Discussions <ckan-dev at lists.okfn.org>

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