Release schedule clarifications
torsten.rahn at credativ.de
Wed Oct 24 20:32:52 CEST 2007
I have just arrived from the first two days of Systems fairs in Munich.
There we collected quite some user feedback as well as experience about how
current KDE SVN (monday, 23rd october) as well as the openSUSE Beta3+ Live CD
performed on different machines.
Judging from the experience we gained there I'd like to support the idea of
labeling workspace + apps "BETA 4" while labeling the API/plattform RC1.
In detail we noticed the following:
- Almost all visitors who had been long-time KDE enthusiasts and were known
for early feedback in the release cycle had completely failed to participate
in our Beta program so far (and I know some of these people since about 8
Most of them had tried to build the KDE betas, failed to see a desktop / panel
appearing and therefore assumed that the apps were not worth testing at the
This is rather alarming given that during a late Beta cycle the targeted beta
testers should have moved from the developers to the enthusiasts.
Therefore the only Beta that gave a chance to participate in Beta testing is
the OpenSUSE Beta3+ Live CD as this Beta release was the only one that showed
a start button and a menu. Even the experience of the Beta3 was often dubbed
as that of an "early Beta" - as opposed to a "late Beta" - which is quite of
a stretch already.
I'd also like to point out that so far KDE 2.0 was certainly our most
problematic release. However even for that one the participation of
enthusiasts was a whole lot better. KDE 2 RC1 still had rough edges (more so
than any other release until KDE 4). KDE 4 on the other hand still has got a
lot of holes (calling it "rough edges" would be euphemism) in addition to the
While many apps work very well the workspace (plasma) still has serious
problems in terms of performance as well as quite some gotcha's in terms of
So in summary I'm perfectly fine with an imminent API freeze (however that
part is not my expertise, so I leave it to others to judge about it).
However calling the current state of the workspace + apps anything beyond
BETA would be dishonest and would certainly generate quite a bit of
irritation among press and enthusiasts as it would skew common definitions of
technical terms in software development extremely.
That all being said the late progress especially with regard to plasma has
been totally amazing. It's clearly visible that we are getting nearer to the
release each day and that KDE 4 has got a lot of potential to be an awesome
However we should avoid to jump the gun to make sure that we won't loose trust
among enterprise people (who already now _do_ watch KDE 4.0 closely even if
they evaluate to deploy KDE >=4.1) and to avoid that we generate unnecessary
On Wednesday 24 October 2007 16:27:05 Dirk Mueller wrote:
> On Sunday 21 October 2007, Cornelius Schumacher wrote:
> > (all deadlines are due 23:59 UTC)
> > 24 October (Wed): KDE 4.0 Release Freeze
> I don`t really like to work in the middle of the night though. I`ve had a
> short look at the state of today, assuming that I`m supposed to tag a final
> release of the KDE 4.0 platform.
> These are the current list of showstoppers:
> a) it does not even compile (see http://ktown.kde.org/~dirk/dashboard)
> b) even if it would compile, it doesn`t really start up for me.
> b) there is no way currently to define a platform version number different
> than the KDE version number.
> c) kdebindings does not compile ATM
> Regarding b), does it make sense to rename the current KDE_VERSION into a
> KDE_PLATFORM_VERSION and export a KDE_WORKSPACE_VERSION (not sure where we
> should get it from, has to be generated from somewhere within
> kdebase/workspace). This would be source incompatible, thought the fallout
> could be fixed pretty easily (unfinished patch attached, just to get the
> > - Deep freeze (changes only by release team)
> I don`t like the "deep freeze" terminology. I would like to have everybody
> else fix the build instead of the release team. Especially those that broke
> it ;)
> Also, I find it hard to believe that we want to go from a nearly "ignored"
> Beta3 state to a "4.0 final" state for the platform without a release
> candidate inbetween.
> The additional trouble is that the new release schedule asks for a
> kdebase-runtime tarball, which does not exist yet. So I first have to
> create one and that is probably not easy in the first try. That alone
> justifies a release candidate for me.
> So, my current plans are:
> a) fix the build
> b) sort out the version number mess.
> c) do a release candidate build tomorrow morning.
> d) decide on the feedback (which hopefully comes :) )
> Another issue that doesn`t seem to be solved so far is that we don`#t have
> a clear list of things that are just there that are going to be deprecated
> with the 4.0 release (kjsembed? khtml? kjs? plasma layouting stuff which (I
> heard rumours) is going to be deprecated with Qt 4.4?)).
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
More information about the release-team