[ckan-dev] RFC ckan releases

[Rufus Pollock]

Sounds like you want a proper develop branch as per (i.e. develop
separate from master):

<http://nvie.com/posts/a-successful-git-branching-model/>

We talked about this when the current workflow was designed I believe
and I'm never quite sure why develop and master sort of got merged but
they did (I think main point was that having master as develop made
people better about only merging working code to develop/master but I
think one could just enforce that via buildbot and general feedback!).

Anyway I leave it to you guys to discuss this further :-)

Rufus

On 1 May 2012 13:17, Toby Dacre <toby.okfn at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>



-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/