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

[Toby Dacre]

My thoughts on this is that it would be nice to have extensions that just
work and do not need to be updated just because ckan has changed.

Once an extension is ckan 2.0 compatible (and correctly written) then it
should work for all future versions of ckan. Therefore there would be no
need to release a 2.0, 2.1, 2.x of the extension.  This is mainly about
using plugins.toolkit as the only method of integration with ckan.  Now
that we can call get_action() without a context the last main hurdle has
been removed as extensions needed to import ckan.model before this.

2.0 also moves to Jinja2 so it is a good cut off point or else we need
multiple templates or keep genshi ones (but it would be nice to remove
these in 2.1 or 2.2)

Hmm

This is all a bit messy.  My main desire with extensions is to isolate them
from core as much as possible to allow refactoring without breakage.

As a reminder if we need new things added to the toolkit then this is
possible if they make sense and we are happy to support them long term.
But much of the issue feels is about how extensions are written so for
exam[le I don't think they should ever include lib.helpers but the can
access any helper functions within their templates for example - again this
gives us flexibility that we need to maintain the code and give power to
the end user.

It would be nice to have better extension writing guidelines at some point.

tobes


On 17 January 2013 11:29, Sean Hammond <sean.hammond at okfn.org> wrote:

> I agree. I think to keep it simple and consistent our recommendation
> should just be that extension branches track the CKAN master and release
> branches, even though in reality, very new or simple extensions will
> probably only have the one master branch (but by the time they have
> conditional behaviour like googleanalytics does, we should just
> recommend them to use the branches).
>
> We'll have to change the install instructions in the README file of each
> extension, and probably mention it for extension authors in the 'writing
> extensions' sphinx docs too.
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130118/c442f25e/attachment-0001.html>