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

[Adrià Mercader]

Hi,

I've been giving some thought to this issue and we talked about it
with David a while ago.
I think that for relatively simple extensions like the googleanalytics
we may be able to follow a unique branch approach like the one you
suggest, and use functions in the plugins toolkit like
requires_ckan_version and check_ckan_version to things depending on
the version.

But long term I think we should follow an branch-based approach like
on ckan core, with branches for each release, as John suggest. E.g.
harvest and to a lesser extent spatial ave undergone a significant
refactor taking advantage of stuff only available on 2.0. Having to
maintain the code base for supporting 1.x would be a lot of work (that
considering that the 1.x line was compatible between versions :) )

Having release branches on extensions would be a bit less convenient
when installing them, as users would have to make sure to checkout the
one that matched the core version, but will ensure compatibility.
We'll need to make sure to document prominently this.

Adrià

On 16 January 2013 16:59, Sean Hammond <sean.hammond at okfn.org> wrote:
> Hey all,
>
> This is something we should probably get down in the extensions docs or
> on a wiki page before we release 2.0.
>
> If an extension wants to support both 1.x and 2.0, how should it do it?
>
> ckanext-googleanalytics supports both:
>
> https://github.com/okfn/ckanext-googleanalytics
>
> I gave it public, templates and legacy_public and legacy_templates dirs,
> and I made it look for the ckan.legacy_templates option in the config
> file and tell CKAN which dirs to use accordingly.
>
> But it's not just templates, there can also be Python differences, e.g.
> you import and use something that is new in 2.0 then your extension
> crashes in 1.8. You could again make the behaviour conditional on the
> CKAN version.
>
> But maybe it should be done with the master branch being 2.0 and a
> legacy branch for 1.x, and then just put install instructions for both
> 2.0 and 1.8 (saying to checkout the legacy branch) into the README on
> the master branch. The code would be simpler. If you added new features
> to the extension you'd have to manually port them to the legacy branch
> if you want them to work in 1.x. But I imagine a lot of extensions would
> not bother with 1.x support for new features,
>
> _______________________________________________
> 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