[ckan-dev] RFC ckan releases

Tue May 1 14:00:16 UTC 2012

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

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!

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
>