[ckan-dev] RFC ckan releases

Tue May 1 14:12:51 UTC 2012

On 1 May 2012 15:00, Adrià Mercader <amercadero at gmail.com> wrote:

> Hi,
>
> It looks like we've been thinking on the same stuff :)
> I wrote my thoughts on this etherpad, along with some other release
> related stuff (extensions, next dates...)
>
> http://ckan.okfnpad.org/releases
>

looks good

>
> I think we pretty much agree on principle (1.x releases vs 1.x.y),
> except maybe on having new features on the 1.x.y releases or not.
> In any case, I think it's a hugely useful debate!
>
>
yeah,  I think the main difference I see is where 1.x.y branches from I'd
like it to branch from 1.x whereas your notes seem to imply branching from
master.  so in my way we only feature freeze for 1.x branches as the 1.x.y
are cherry picks. I think that 3 weeks for a 1.x is a little too quick I'd
prefer a 4 week cycle but keeping it flexible.

On a separate note has anyone contacted dread about his 1.6.1 branch as it
seems to be incorporating quite a lot of changes around the login/cookies
stuff and seems to be a moving target and I'd not want them included
without quite a bit of qa first   Is he expecting to backport our changes
and maintain that branch or for us to take them?  @dread if you read this
what are your thoughts?

Toby

> We can have a look after or during the 16:00 meeting.
>
> Adrià
>
>
> On 1 May 2012 13:41, Toby Dacre <toby.okfn at gmail.com> wrote:
> >
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > ckan-dev mailing list
> > ckan-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/ckan-dev
> >
>
> _______________________________________________
> 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/de944d14/attachment-0001.html>