2.8.x maintenance plan and 2.9 ?

[Jaroslaw Staniek]

On 9 April 2014 09:55, Cyrille Berger <cberger at cberger.net> wrote:
> On 2014-04-09 09:07, Jaroslaw Staniek wrote:
>>
>> Dear All,
>> I proposed regular patch releases at
>> [http://mail.kde.org/pipermail/calligra-devel/2014-April/010821.html
>> [3]]. Practically this would be like below:
>>
>>
>> 2.8.2 May 3
>> 2.8.3 May 31
>> 2.8.4 June 28
>> 2.8.5 July 26
>> 2.8.6 Aug 23
>> 2.9.0 Sep 20
>
>
> We already have regular patch releases plan:
> http://community.kde.org/Calligra/Schedules/2.8/Release_Plan
>
> They are currently set on: +2 weeks for .1, +3 weeks for .2, +1 month after
> that.
>

Sure, based on experience I am just concerned about not offering
patches in July, August and maybe September.

>> In this approach the number of releases (and time between them) is
>> more important than exact dates. We can skip a release but we never
>> know today, so it's better to have a plan.
>
>
> It seems to me that having no published plan is better than having a plan
> that we don't follow. That is why I haven't put anything after 2.8.4,
> usually there is not much happening then anymore.

Calligra has many apps so common agreement that we may need a release
would be nice.
The longer time people use the software, there are more chances
there's need for another patch release. People do not heavily test
upfront at beta or even rc stage.

>> I have to admit, without covering the time with regular releases,
>> users that depend on certain improvements of Kexi have to build master
>> by hand... It's a constant work-in-progress state because of how big
>> the app becomes (5 apps in one actually and growing).
>>
>> I am willing to help with some release tasks (when not AFK once or
>> so).
>
> What is really needed is someone to work on the changelog. The best for
> patch releases would be to have some automatic tool, but in lack of that,
> someone who volunteer to hand collect from the changelog the relevant item
> would be very appreciated.

Automatizing thinks is definitely the way to go for our budget :)
I am thinking about extending our git pre-commit hook to force FEATURE
and FIXED-IN keywords...
More about that later.


-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt for Tizen | http://qt-project.org/wiki/Tizen
 Qt Certified Specialist | http://www.linkedin.com/in/jstaniek