[ckan-dev] RFC ckan releases

[Toby Dacre]

hi,

Firstly again to say that the 1.7 release cycle seems a big improvement on
the 1.6 one. However, here seems to be differing takes on what's happening
with regard to releases.

This is how I'd like things to happen (others may disagree - please do)

main releases eg 1.7, 1.8

These would add new features and allow us to change fundamental bits of the
code as we do now.  We would branch from master, stabilise, qa etc and then
release.  Personally I'd be happy with a time based release like the linux
kernel rather than strict feature releases.

point releases 1.7.1 etc

These would branch from the last stable release eg 1.7 they would only
include bug fixes that would be cherry picked from master (to ensure that
the bugfix is in master).  New releases would be governed by bug
severity/impact.


Doing this would make it easier to make large changes to the codebase as we
would have a larger window say 4 weeks eg I've done some cleaning of the
models and I'd like these to get in 1.8 but I think the changes are too big
for 1.7.1.  If there is any risk that 1.7.1 will merge in master I won't
push these changes into master but then I need to keep my branch updated
regularly which risks introducing errors as I can end up with many merge
conflicts if anyone goes near that code.

The last place I was working for one project we moved from a release every
2 weeks to a system like above with a new release every ~ 4 weeks (they
were feature releases) and a stable branch that only received bugfixes.
This helped us hugely as we ended up with a much more stable product often
we would only use the new branch limitedly till the first bugfix release -
there was always one ;) and then generally roll out to other instances.
Also it removed a large overhead around releases as this was less regular
especially testing.  I think it also made us better at getting features
into releases as we had time to do them properly rather than having to
squeeze them into two week windows.

I think that having larger development windows will improve our planning in
general especially when it comes to things like performance and
template/js/css cleanups.

Toby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120501/ea5dd319/attachment.html>