[ckan-dev] [Services-coord] Extensions supporting different versions of CKAN

Mon Aug 12 18:15:18 UTC 2013

Hi,

Sorry, I disagree :)
Comments below

On 12 August 2013 18:12, Sean Hammond <sean.hammond at okfn.org> wrote:

> I'd like to propose an alternative way to specify what branch of an
> extension should be used with a given branch of CKAN.
>
> The current policy is explained here:
>
> http://lists.okfn.org/pipermail/ckan-dev/2013-May/004824.html
>
>> When installing an extension, developers should always use the
>> "stable" branch [of the extension], unless there is a specific branch
>> that targets the CKAN core version they are using.
>
> But honestly I don't think this is a workable policy, and I'm having
> trouble explaining it in the writing extensions documentation.
>

I will totally accept that this wording does not cover some cases and
that it might be confusing but (as discussed quite a lot on previous
occasions) I think that it gives a good balance between ease of
install and development and maintainability.

Maybe this little change helps:

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

> Problems:
>
> - If an extension is developed during the CKAN 2.2 days and has a stable
>   branch that supports 2.2, then some breaking changes are made in CKAN
>   and released in CKAN 2.3, then according to the policy above the
>   extension's stable branch should work with CKAN 2.3 but in fact it
>   doesn't.
The policy assumes that before each release extensions will be checked
against core and their branches updated accordingly.
In this case the extension's stable branch should be updated to work
against 2.3, and if for some reason both 2.2 (and previous versions)
and 2.3 can not be supported in the same code base (using
check_version, etc), a new release-v2.2 branch should be created,
which would be the one used for ckan<=2.2. Ideally though we should
avoid this, and try to support different versions on "stable" (up to a
sane point of course)

> - What happens if an extension has branches master, stable, and
>   release-v2.1, and I'm using CKAN 2.0?
You use release-v2.1 as it is the higher version closer to the one you are using

> - What if an extension has branches master, stable, release-v2.2 and
>   release-v2.0 and I'm using CKAN 2.1?
You use release-v2.2 as it is the higher version closer to the one you are using

> - Every time you commit on master you're then going to have to
>   cherry-pick that commit onto stable and potentially onto release
>   branches as well
Yes. There is no way around this. I've been doing it for some months
in spatial and harvest.
I suspect that most policies that we come up with will involve this
(as it happens in core)

> - No way for an extension to clearly indicate which versions of CKAN it
>   does and doesn't support
This is not related to the policy per se, nothing is preventing from
adding this functionality.

> Maybe instead we add a paster command to all extensions. If you want to
> know what branch of an extension you should use with a given CKAN
> branch, you run the extension's `paster branch` command:
>
>     $ paster --plugin=ckanext-spatial branch release-v2.0
>     master
>
> this means that with CKAN branch release-v2.0, you should use the master
> branch of ckanext-spatial.
>
> This way we don't have to come up with a branching policy for extensions
> that covers all cases and doesn't have any disadvantages (like requiring
> too much branching and cherry-picking). Each extension can just define
> its own.
I totally agree that this command could be useful for installing or
packaging, or even development, but it should reflect whatever policy
we agree, not be the policy on itself
Having the command and allowing free reign among extensions is a bad
idea and will be confusing for users, we should be consistent to make
both installing and development predictable, at least to a degree.

Bottom line is that we should aim gradually to stop breaking core and
extensions on each release. Ideally extensions should run of "stable"
almost always and only from time to time we should need to create a
new release branch on an extension. We have a couple of functions
available on the toolkit for this (requires_ckan_version,
check_ckan_version).

> Also it's good for scripting, if you were for example writing a CKAN
> install or upgrade script, it can ask each extension which branch it
> should check out.
>
> You should always checkout the master branch of the extension and pull
> the latest commit, before running the `paster branch` command.
>
> We'll change the template extension that the
> `paster --plugin=ckan create -t ckanext ...` command creates to include
> a default version of this paster command that always returns 'master'.
>
> Extensions can then modify the function to do whatever they want. This
> function should always be pretty simple, e.g.:
>
>     def branch(ckan_branch):
>         if ckan_branch == 'release-v2.2':
>             return 'release-v2.2'
>         elif ckan_branch in ('release-v2.1', 'release-v2.0'):
>             return 'release-v2.1'
>         elif ckan_branch == 'master':
>             return 'master'
>         else:
>            raise Unsupported
>
> Raising an exception and exiting with non-zero exit status means the
> given branch is not supported.
>
> _______________________________________________
> Services-coord mailing list
> Services-coord at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/services-coord
> Unsubscribe: http://lists.okfn.org/mailman/options/services-coord