Release schedule clarifications

[Cornelius Schumacher]

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.

Maybe the tagging should not happen right at the deadline, but after things 
have settled a bit, let's say in the middle of the "deep freeze" (to be 
handled flexible of course depending on the state of the code).

> 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
> idea).

Do we need to split this internal version numbers? For the version numbers of 
the tarballs it doesn't matter, right? 

As there are simultaneous releases of platform and workspace, one can deduce 
the version number of the workspace from the platform version number. Hm, 
unless somebody upgrades platform, but not workspace.

Wouldn't we need library specific version numbers anyway? Probably only, if 
distributors split up things in a different way than we do with the tarballs. 
Do they do this?

> > - 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 ;)

So what about replacing the "changes only by release team" by "only allowed 
changes: compile fixes, reviewed fixes of blocker bugs, changes needed to 
build the release tarballs"

> 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.

It seems to be consensuse to go with Platform RC1 (that would be 3.95 then) 
and Workspace and Applications Beta 4 (that would be 3.95 as well).

The 14th November deadline would than be Platform RC2 final (4.0.0) and 
Workspace and Applications RC 1 (3.96).

> 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.

Agreed.

> 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 :) )

Sounds good.

> 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?)).

You mean deprecated with the 4.1 release? For the 4.0 release I suppose the 
obsolete parts are marked (or already removed).

-- 
Cornelius Schumacher <schumacher at kde.org>