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 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
