[ckan-dev] RFC ckan releases

Tue May 1 12:41:14 UTC 2012

On 1 May 2012 13:25, Rufus Pollock <rufus.pollock at okfn.org> wrote:

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

To be honest I'm happy with using master as a dev branch because it always
will be to some extent.  This is more about our release branches and how we
deal with them. the less branches (excluding feature creation ones etc) the
easier the workflow in my experience. but managing/gatekeeping the
release/stable ones is where the effort needs to go.  So no I don't want a
develop branch.

I'm happy with anyone merging into master (within limits) but getting stuff
into the release/stable branches needs to have someone controlling it (they
don't need to do all the work but they need to agree what's going to get
in).

Splitting the release from master needs a little thought but as it only
happens rarely this becomes quite easy and non workflow blocking.

I think we are moving in a good direction as we are now I just would like
to nudge it a bit further along the road.

thanks for the feedback
Toby

>
> <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/
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120501/b0518eb9/attachment-0001.html>