Release schedule clarifications

[Allen Winter]

On Wednesday 24 October 2007 06:59:05 pm Cornelius Schumacher wrote:
> 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).

I think we keep our tradition of making deadlines at Midnight Your Timezone.
Dirk can tag whenever he feels the time is right.  We keep our "deep freeze"
(for lack of a better term) in place until the tagging is done.

> 
> > These are the current list of showstoppers:
> >
> > a) it does not even compile (see http://ktown.kde.org/~dirk/dashboard)
hopefully things will compile better tomorrow.

> > b) even if it would compile, it doesn`t really start up for me.
starts for me ok.

> > b) there is no way currently to define a platform version number different
> > than the KDE version number.
hmm.. yes, it might be handy to say that application vX.Y.Z from KDE A.B.C
is built against KDE Platform P.D.Q.  Especially for keg apps that don't
necessarily belong to KDE A.B.C.

> > c) kdebindings does not compile ATM
Richard says he fixed the kdebindings compile.  

> >
> > 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).
> 
Can we leave KDE_VERSION as is, but introduce the a new KDE_PLATFORM_VERSION?

> 
> > > - 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"
>
That seems reasonable.  Still need something to replace "deep freeze".
How about "tagging freeze"?
 
> > 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).
> 
Yep.

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

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