[ckan-dev] release date for 2.4

Wed Mar 18 15:21:44 UTC 2015

Coolio, so let's ship 2.4 on 4 June. 2.5 on 4 Sept and then 3.0 on 4 Dec.
Then 3.1, 3.2, 3.3 and 4.0 on a similar schedule in 2016.

Does that work?

On Wednesday, March 18, 2015, David Read <david.read at hackneyworkshop.com>
wrote:

> Steven,
>
> We do 'point-point' releases (e.g. 2.3.1) without a timetable. It might be
> a sudden security issue, or back-ports, released with an appropriate
> urgency. Point-point releases have an established meaning, process and
> frequency. So unless there is support for a change, I think the tech team
> should be left to manage the details of these.
>
> We're discussing normal 'point' releases (e.g. 2.4) which have been every
> 3 or 4 months. I don't see why you'd want to delay them to 6 months. I
> think it's great that you're drumming up interest and people for new
> features, but they can slot in whichever release is next whenever they are
> ready. There's no reason to delay hum-drum releases, with fixes and general
> improvements that devs really appreciate, every 3 months.
>
> Dave
>
> On 18 March 2015 at 14:56, Steven De Costa <
> steven.decosta at linkdigital.com.au
> <javascript:_e(%7B%7D,'cvml','steven.decosta at linkdigital.com.au');>>
> wrote:
>
>> Thanks David. Regular patch releases sound great, needed and appropriate.
>> So 2.3.1, 2.3.2, etc.
>>
>> Six months would be a good target for 2.4 if we were to consider more
>> significant structure updates via such a cycle.
>>
>> And, if feature freeze was done in four then it gives vendors two months
>> to update integrations, etc. Then the whole world moves forward with the
>> release together.
>>
>> I think CKAN is the kind of thing that can be a core component of
>> other hybrid systems so I'd hope to encourage such adoption.
>>
>> Please don't let any of these ideas slow anyone down though. When I'm
>> back in the office next week I'll be working through the roadmap features
>> with our team and picking a few to tackle. The main on I'd like Link to
>> help with is the first time install to make it so easy my mum could do it.
>>
>> Hoots!
>>
>>
>> On Wednesday, March 18, 2015, David Read <david.read at hackneyworkshop.com
>> <javascript:_e(%7B%7D,'cvml','david.read at hackneyworkshop.com');>> wrote:
>>
>>> Clearly frequent releases are necessary. I can't tell how you got the 6
>>> months figure but it doesn't feel frequent enough to me. If someone is
>>> doing a block of customizing, it might take 1 or 2 months. If they want a
>>> new feature or bugfix and its not going to be released for several months
>>> then they are more likely to fix it themselves on their own fork of ckan,
>>> will be further from master and less likely to contribute it back.
>>>
>>> The 2.3 release was exceptional for being almost 13 months after 2.2.
>>> Nearly all previous releases were spaced 3 or 4 months after the previous
>>> one.
>>>
>>> The policy has been to just release regularly every three months. This
>>> was disrupted in the last release by the premature merging of a large and
>>> incomplete feature, and perhaps the notion that OKF was passing
>>> responsibility for releases to the CKAN Association. If we work to keep the
>>> master branch in a useful state then it shouldn't become an issue again.
>>>
>>> What does need addressing is the cost of doing a release. I guessing it
>>> is a few days work. I think the tech team should review it, minimize the
>>> cost and codify it to make it easier for other people to do it, aside from
>>> Adria.
>>>
>>> David
>>>
>>> On 16 March 2015 at 14:40, Steven De Costa <
>>> steven.decosta at linkdigital.com.au> wrote:
>>>
>>>> Two thumbs up is a good start :)
>>>>
>>>> I'd add that part of the motivation for routine six month releases is
>>>> to allow a commercial ecosystem to then build their own roadmap on top of
>>>> that of CKAN cycle.
>>>>
>>>> This will help paid members of the association justify the business
>>>> case for investment in the project, whether it's in-kind or cash.
>>>>
>>>> The main idea I have for release management is to break apart the
>>>> product definition from the product development and product support
>>>> workloads. Then we can recruit different types of people with great skills
>>>> into each area of effort. (No exclusions though. People can get involved in
>>>> all areas if they wish)
>>>>
>>>> In addition, the product definition team would release EOIs to identify
>>>> if there are funding sources that could then be used to accelerate
>>>> development of features. A fund for feature X would then be market demand
>>>> driven. The vendors listed as CKAN suppliers could then pitch to develop
>>>> feature X as a paid project.
>>>>
>>>> Some conflict of interests need to be managed, but I figure that would
>>>> be a great problem to have if we first had the funding created :)
>>>>
>>>> The C&C Team would have the job to promote roadmap features and attract
>>>> funding.
>>>>
>>>> I think much of the technical release management would remain in the
>>>> tech team as it has. They'd just have a deadline constraint for shipping.
>>>> But, they potentially have a lot more support from other teams too.
>>>>
>>>> My own experience with 2.3 was that I really wanted to help, but for
>>>> various reasons it was hard. A lot of my suggestions here are taken from
>>>> that experience and thinking about ways companies like mine or initiatives
>>>> people like me can support might more easily be leveraged to ship new
>>>> features.
>>>>
>>>> I have zero criticism and all applause for everyone involved in the 2.3
>>>> release. In fact my deep gratitude is a debt I need to repay.
>>>>
>>>> #WeAreCKAN
>>>> Steven
>>>>
>>>>
>>>> On Monday, March 16, 2015, Claire Reis <Claire.Reis at umanitoba.ca>
>>>> wrote:
>>>>
>>>>>  I think releasing 2.4 in September is a great idea as well.
>>>>> Geospatial is also of interest to our group as we add more datasets and
>>>>> upgrade our CKAN instance (http://130.179.67.140/).
>>>>>
>>>>>
>>>>>
>>>>> I’d also be interested to hear more about your plans for release
>>>>> planning and management activities Steven.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Claire
>>>>>
>>>>>
>>>>>
>>>>> *From:* Ross Jones [mailto:ross at servercode.co.uk]
>>>>> *Sent:* March 16, 2015 03:37
>>>>> *To:* CKAN Development Discussions
>>>>> *Subject:* Re: [ckan-dev] release date for 2.4
>>>>>
>>>>>
>>>>>
>>>>> Hi Steven,
>>>>>
>>>>>
>>>>>
>>>>> That sounds great to me - what does everyone else think? It's be great
>>>>> to get the community's opinion on whether that would be too soon, just
>>>>> about right etc?
>>>>>
>>>>>
>>>>>
>>>>> My hope is that with more frequent releases the upgrade process would
>>>>> be even simpler and we can share around the workload of managing the
>>>>> release.
>>>>>
>>>>>
>>>>>
>>>>> We've had a couple of people express interest in Geospatial and
>>>>> Workflow as things that could be prioritised - and I think, particularly
>>>>> the workflow in particular might be a really good place to start.
>>>>>
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> Ross
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  On 14 Mar 2015, at 03:39, Steven De Costa <
>>>>> steven.decosta at linkdigital.com.au> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi folks,
>>>>>
>>>>>
>>>>>
>>>>> Further to the comment from Ross about the roadmap and heading toward
>>>>> a 2.4 release I discussed this with Rufus last night.
>>>>>
>>>>>
>>>>>
>>>>> I'm keen for us to target 4 September as the release date and work
>>>>> backwards from that as a hard deadline.
>>>>>
>>>>>
>>>>>
>>>>> What are the reactions to that date and suggested approach?
>>>>>
>>>>>
>>>>>
>>>>> I'm keen to pull more people into the dev work and would do whatever I
>>>>> can to help. I say that also from my C&C Team and Steering Group
>>>>> perspectives.
>>>>>
>>>>>
>>>>>
>>>>> I also have a few ideas on how to support release planing and
>>>>> management activities, largely from a non dev track, so that the dev folks
>>>>> can be 100% on the code and coolness of CKAN.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Steven
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *STEVEN DE COSTA *|
>>>>> *EXECUTIVE DIRECTOR *www.linkdigital.com.au
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ckan-dev mailing list
>>>>> ckan-dev at lists.okfn.org
>>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *STEVEN DE COSTA *|
>>>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ckan-dev mailing list
>>>> ckan-dev at lists.okfn.org
>>>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>>
>>>>
>>>
>>
>> --
>> *STEVEN DE COSTA *|
>> *EXECUTIVE DIRECTOR*www.linkdigital.com.au
>>
>>
>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> <javascript:_e(%7B%7D,'cvml','ckan-dev at lists.okfn.org');>
>> https://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>
>>
>

-- 
*STEVEN DE COSTA *|
*EXECUTIVE DIRECTOR*www.linkdigital.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150319/8ef9fb6a/attachment-0003.html>