[UPDATE] KDE 4.0.0 Release Schedule

[Allen Winter]

On Sunday 16 September 2007 6:25:42 pm Alexander Neundorf wrote:
> On Friday 07 September 2007 10:03, Allen Winter wrote:
> > Howdy,
> >
> > We, The Release Team, hereby announce that we are accelerating the
> > KDE 4.0.0 schedule [1]  2 weeks by removing 1 Beta and slightly
> > extending the Release Candidate cycle.
> >
> > Additionally, we are introducing a new "KDE Development Platform"
> > release to occur in late October.  These release will contain all the bits
> > and pieces necessary to develop KDE4 applications; meaning it will
> > include kdesupport, kdelibs, kdepimlibs and kdebase/runtime.
> > NOTE the earlier freeze date for these modules and make sure you
> > don't miss the deadline (3 Oct) to get your fixes in.
> >
> > The schedules look like this:
> >
> > KDE 4.0.0 Development Platform
> > =========================
> > For modules: kdesupport, kdelibs, kdepimlibs, kdebase/runtime
> > 3 October (Wed): Freeze -- Only critical bugfixes allowed after this date
> > 24 October (Wed): Tagging
> > 30 October (Tue): Release KDE Development Platform 4.0.0
> 
> It hasn't really been mentioned, so here I ask:
> how do these freezes effect cmake ?
> 
It seems logical to freeze CMake and all the CMake files
at the 3 October "Development Platform". I'll add this
to the Release Schedule (unless there are objections).

> What I'd still like to do:
> -merge KDE4_ADD_TEST_EXECUTABLE() into KDE4_ADD_EXECUTABLE(... TEST ...), must 
> be before 4.0. I hope I can do this this week.
> 
OK

> -go through the FindKDE4Internal.cmake and KDE4Macros.cmake and check that 
> everything's still consistent and we offer a nice cmake interface for KDE. 
> This can bring up more issues like the one above. E.g. the new 
> KDE4_ADD_APP_ICON() macro may need renaming.
>
Consistency is good.
 
> -KDELibsDependencies.cmake may need some changes (for Windows: no fixed paths, 
> no "+" in library names)
> 
> -maybe some changes may be required for Windows (mainly installation related)
>
Fixes are are always permitted, even after the freeze.
 
> -cleanups where required
> 
Certainly as long as nothing breaks.

> The problem is, from september 22nd to october 7th I'll most probably won't 
> have any internet access because I'll be moving back to Germany. I hope to 
> have internet access after that, but it may take to november to have full 
> access again.
>
That is a problem.  So you have about 4 days to make all these fixes
and also pack/prepare for your return trip.  Doesn't seem possible.

How about this:  try to get macro name changes; consistency changes;
other "interface changes" fixed before you leave.  Then we can
worry about "bugfixes" after 3 October (require review on the MLs).

> Would it be ok to require a newer version than CMake 2.4.5 for Windows ? I 
> think we should allow this if it may be required.
> 
> Ralf, Christian: which version of cmake are you using, is 2.4.5 good enough on 
> Windows ?
> 
We can require a higher version for Windows if necessary.
Is there any reason to also require a higher version on non-Windows?

> 
> I'm not subscribed to the release mailing list, since I don't feel like part 
> of the release team, but I think especially for a "KDEDK" release cmake 
> should be taken into account.
> 
Thanks for bringing this up.
Another thing:  we really should have a TechBase page that documents
all of our KDE4 specific variables and macros for CMake.  

I'll start such a page today.  Mostly a skeleton.

-Allen