Frameworks/Policies

The strategy and policies for the KDE Frameworks effort is yet to be discussed and decided.

http://thread.gmane.org/gmane.comp.kde.devel.frameworks/37

This page is a starting point for further expansion.

Frameworks have a Tier and a Type

Each framework has a clear position in the Tier/Type matrix, its position forces a set of rules on its possible dependencies. This matrix and its rules are summarized in the Frameworks matrix document.

The constraints from Tiers are the following:

Tier 1 Frameworks can depend only on Qt official frameworks or other system libraries;
Tier 2 Frameworks can depend only on Tier 1 Frameworks, Qt official frameworks, or other system libraries;
Tier 3 Frameworks can depend only on other Tier 3 Frameworks, Tier 2 Frameworks, Tier 1 Frameworks, Qt official frameworks, or other system libraries.

The constraints from Types are the following:

Functional Qt Addons cannot have runtime dependencies;
Integration Qt Addons can have an optional runtime dependencies and aim at integrating with the underlying OS/Platform;
Solutions have a mandatory runtime dependencies, it is part of their design and where their added value comes from (think scalability, resource sharing, resilience, etc.).

Framework directory structure

All the frameworks will have the same directory structure which will follow some rules:

The containing directory has the name of the technology (plasma, kio, itemmodels, etc.);
At the top level we find the common files like README, TODO, MAINTAINER, etc.
More comprehensive documentation go into a docs subdirectory
The source code for the targets go into src subdirectory, if several payload are built (like a core lib and a gui layer on top) then src will contain one subdirectory per library: core, gui, widgets, etc.
Code examples go into an examples subdirectory
Automatic tests go into an autotests subdirectory
Test applications go into a tests subdirectory
CMake modules (FindFoo.cmake etc.) or CMake macro files go into cmake subdirectory

Frameworks have automatic unit tests

Enough said really... They must be unit tested with automatic unit tests.

Corollary: When fixing a bug in a framework, the auto-test proving the bug and the fix should come in the same commit

Frameworks maintain binary compatibility

Just like we did in kdelibs, KDE Frameworks maintain the binary compatibility through their life time, for more details see the binary compatibility policy on techbase.

Note however that this policy is lifted during major version transition, corresponding epics of milestones will be marked as such.

Frameworks commits are reviewed

Make sure all commits in the master branch of a repository part of the KDE Frameworks got a proper review. As such commits must contain either a "Reviewed by:" (for quick pastebin reviews) or a "REVIEW:" (for more formal reviewboard reviews).