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

Sean Hammond sean.hammond at okfn.org
Tue Aug 13 10:28:27 UTC 2013


Alright, let's forget about the paster command idea since it's not
something we can implement right now anyway even if we wanted to do it.

But about the branching policy itself - in the 99% case when the master
version of CKAN hasn't broken extension compatibility with the latest
release version, wouldn't it be easier for extensions to just have the
master branch and tell users to use that (whether they're using CKAN
master or the latest release version), rather than maintaining two
branches master and stable and having to keep them in sync all the time?

Then in the 1% case where the code on CKAN master is incompatible with
the latest release (2.1, say), as soon as the extension developer starts
committing code on master that's incompatible with 2.1 they make a
release-v2.1 branch of their extension to contain only the
2.1-compatible code.

The point is, you only make a new branch when you actually need a branch
because the code on it is going to be different from master. You may
still have to cherry-pick some changes from master onto release-v2.1 if
you want to backport those changes, but you only have to do this when
it's actually necessary, you don't have to sync these master and stable
branches all the time.

I'm not sure I see the advantage of adding in the stable branch?




More information about the ckan-dev mailing list