Initial revision of KDE 4.1 schedule available on Techbase

[Torsten Rahn]

Hi,

I mostly agree with Dirk. 

Personally I think that the current proposed schedule is unrealistic in terms 
of timescales. Having 2.5 months between an Alpha Release and a Final Release 
simply won't work.

I'd suggest to have an Alpha Release  in March, the first Beta at the end of 
April, the second Beta at the end of May and the Release Candidate at the end 
of June / begin of July. This would make sure that people get into release 
mode early again (otherwise we'll have too many construction sites still two 
months before the actual release).

I think that the points of times for freezes and their definitions as 
suggested by Matt are quite good actually. I just feel that people won't get 
into release mode this fast, so we need to have a "real" alpha release in 
March first (and basically call your Alpha1 a Beta 1, etc.).  

Regards,

Torsten


> On Tuesday 12 February 2008 19:01:10 you wrote:
> > On Saturday 26 January 2008, Matt Rogers wrote:
> > > I've posted a new schedule on
> > > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Sche
> > >du le that should work as the nearly final release schedule.
> > >
> > > Feedback is appreciated.
> >
> > I have a couple of questions:
> >
> > a) "Binary compatibility is not required". what do you mean by that?
> > you're saying that newly added features do not have to be binary
> > compatible? you're saying that binary incompatible changes are allowed in
> > kdelibs?
>
> That was something I ripped from the 3.5.x release schedule. It's intent is
> to say that BC will not be guaranteed for new API.
>
> > b) Why a hard feature freeze for alpha1, e.g. before any user announced
> > release? that doesn't make sense. we should have alpha releases that
> > attract user attention and be able to react to the feedback, which often
> > means changing or implementing new features. imho the feature freeze
> > shouldn't be before beta1 or beta2.
>
> This is, again, something I did based on the 3.5 schedule. We can push the
> feature freeze off until later. No problems for me.
>
> > c) Why a message freeze before beta1? bugfixes often require message
> > changes.
>
> hehe, ok, so maybe basing my wording on the 3.5.x release schedule wording
> wasn't such a good idea. When do you think it would be a good idea to put a
> message freeze in place? RC 1? I don't particularly have a preference.
>
> > d) it is still a mis-aligned schedule, however I'm not going to complai
> > too loudly about it given that it might slip by one month and then be
> > aligned
> >
> > :)
> >
> > e) I like the no-new-artwork freeze.
> >
> > Greetings,
> > Dirk
>
> Thanks for the feedback. I'll work on making the changes. Should be done by
> the end of the week.

-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz