KDE 2.0 Release Plan

Kurt Granroth and Preston Brown are acting as release coordinators for KDE 2.0. 

1. KDELIBS FROZEN

Kdelibs must be frozen to the point that they will not become binary incompatible again for a long time, at least a year or more. However, we do not want to preclude the possibility of making important fixes and additions after the release. For this possibility to exist, we must add private member pointers to each class, and clean out any cruft that still remains. There is a progress chart with graphs here to chart our progress.
2. DOCUMENTATION COMPLETE

All KDE classes included in the libraries must be documented. If a class isn't documented, it shouldn't be included in the final release of the libraries. This probably isn't an option, so that means that some classes will need to have documentation written.

Applications included in kdebase should have basic documentation included that is accurate and up-to-date with any changes that have occurred for that application since KDE 1.x.

Translations should be complete for at least German, French, possibly Spanish, and hopefully many others. 

3. KDEBASE COMPLETE 

Everything included in kdebase must be complete. When we say complete, we don't necessarily mean all functionality is implemented, but if the functionality is indicated to be present, it must work. It must not segfault. It must not say "not implemented." If there is some chunk of code or stub sitting around for future functionality that will not have time to get completed, it should be commented out or somehow hidden. 

Users of KDE 2.0 will be expecting things to function perfectly. It is better to have no functionality than broken functionality in a final release. Broken functionality generates bug reports.

This timeline is very aggressive, but necessarily so. We need to get KDE 2.0 stable and available to develop applications with, as many third party developers are starting to depend on Qt and KDE 2.0 functionality. KDE 2.0 has been in development for over a year at this point. It is time.

Frequently Asked Questions

1. Can I make changes to the libraries after they are frozen?

 

 

That depends. The cardinal rule to follow here is that your change must be binary compatible. Click here for a description on what that means and ways around it.

In simple terms, though, it means that applications should not have to be recompiled after you make your changes.

2. What types of changes can I make after the freeze?

 

 

Almost all changes after the freeze should be bug fixes or completion of existing features. If you have a really cool feature you want to add, please contact the kde-core-devel list first. Bear in mind that unless the feature is really "can't-do-without", you will probably have to wait until a later release.

3. How solid are the dates given?

 

 

Hopefully fairly solid. We won't release anything that isn't ready so if things slip, then the schedule slips. But we really are going to try and meet all of those deadlines.

4. When will KDE 2.0 be released?

 

 

Short answer: "When it's done".

Longer answer: Right now, we're concentrating on getting the first beta out. The release schedule for 2.0 really depends on what shape the beta is in. If it needs some serious work still, then we'll likely do a few more betas. If it's rock solid, then 2.0 will come out very quickly after. 

Really, the more people that contribute bug reports and especially FIXES, the faster 2.0 will be released.

5. Is koffice or kdenetwork or any other package included?

 

 

The only modules that will be monitored for KDE 1.90 are kdelibs and kdebase. All other modules will be examined later.