[Kmymoney-devel] Schedule for future releases

[Ian Neal]

  Thomas Baumgart wrote:
> On Monday 28 December 2009 13:44:58 Alvaro Soliverez wrote:
>> Hello all,
>> as I promised, here is a proposal for a schedule.
>>
>> - move into extragear
>> - sync with KDE SC schedule
>> - short releases before kdereview
>>
>> First of all, if possible, I would like to get KMyMoney into extragear
>>   by KDE SC 4.5. That's about 8 months from now, so I think it is
>> possible.
>>
>> Along with that, I think we should sync KMM releases with KDE. Of
>> course, that has its pros and cons. As a pro, we are more predictable
>> for distros, so they know when to expect a release from us. It has the
>> con that we have to adapt our development to the KDE schedule,
>> including soft and hard feature-freeze, and string-freeze, of course.
>> That means that we only 4 months every 6 to work on new features, and
>> 2 full months dedicated to bug fixing and stabilizing new features.
>> Until KDE moves to git, that might slow our development on new
>> features, specially for those who don't get many bug reports, kind of
>> like happened with the work on porting the widgets for this release.
>>
>> To move to extragear, we have to get KMM into kdereview before freeze.
>> I think that's about May. So, I would go with short release cycles,
>> about 6 weeks each, and have 3 releases before moving to kdereview.
>> Each cycle would be 4-week full development, and 2-week string-freeze
>> and stabilization. The first string-freeze would start about February
>> 1st, which is the end of string-freeze for 4.4, and release of KMM
>> 3.96 about February 15th.
>> KMM 3.97 release would be about March 29th and 3.98 would be mid-May
>> and then move to kdereview.
>>
>> What's your opinion? It also means moving to a tighter integration
>> with KDE, which on one hand opens up possibilities due to the
>> resources it provides, but it also means losing some control (for
>> example, release schedule).
> Since we have agreed on the tighter coupling with KDE this sounds like a good
> plan. It will be rough in the beginning, but remember that we can certainly
> start development of new stuff in a separate sandbox during the string
> freeze. It's what I did here many times. git might come into play here also
> (I still need to read a bit about it, but so far it looks like a cool thing).
>
> So, count me in on the plan.
>
I've created a mercurial repository to work from and using queues with 
that (I did when working on the kmymoney2 cvs source too, just find it 
so much easier to manage multiple patches).

Ian