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

[David Read]

Sounds good Adria,

David

On 4 February 2013 09:22, Adrià Mercader <adria.mercader at okfn.org> wrote:
> 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
>
> _______________________________________________
> 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