Frameworks/Epics/Splitting kdepimlibs

From KDE Community Wiki
Revision as of 10:09, 3 December 2011 by Ervin (talk | contribs) (Created page with "== kdepimlibs splitting epic == === Important Forewords === If you are working on splitting a framework, make sure to consult [[Frameworks/Epics/Splitting_kdelibs/Common_Soluti...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

kdepimlibs splitting epic

Important Forewords

If you are working on splitting a framework, make sure to consult our list of common issues. It will give you an overview of the solutions you're supposed to use to deal with some of the dependencies.

Also, when splitting out a framework, it is part of being done to comply with the KDE Frameworks Policies, it will also need to follow this Epic Policies. Any framework in the staging area cannot move to its final place without following those policies.

And last but not least, if you create a new framework, please consider being its maintainer as well. We need people to ensure the stewardship of all the frameworks.

Existing frameworks

Definition of done:


Status Framework Tier Type Maintainer Comment
IN PROGRESS name Tier X Functional ?? ??

Backlog

Yet to be produced frameworks (foreseen tier and type, not set in stone):

  • akonadi
  • kblog
  • kcalcore
  • kholidays
  • kimap
  • kldap
  • kmbox
  • kmime
  • kpimutils
  • ktnef
  • kxmlrpcclient
  • microblog
  • gpgme++/qgpgme
  • syndication
  • kontactinterface
  • kpimidentities
  • kpimtexteditor
  • mailtransport


Policies

Strive for Source Compatibility

Avoid removing API from the frameworks branch, even if it is replaced or deprecated. Prefer to implement the old API in terms of the new API.

In some cases this is very easy. For example, many APIs in KGlobal will be replaced as part of the frameworks effort.

  • KGlobal::charsets() -> KCharsets::charsets()
  • KGlobal::dirs() -> KStandardDirs::global() (or something?)
  • KGlobal::ref() -> qApp->ref()
  • KGlobal::deref() -> qApp->deref()

etc.

Removing this API from KGlobal is not necessary in most cases, and it introduces a porting burden which is best avoided.

There is unlikely to be a 1:1 mapping of old API to new API in every case, so how to implement the old API may not always be obvious. However, attempting to ensure that the older API remains useful should be at the front of our efforts and standards in the frameworks branch.

Binary compatibility policy relaxed

During the execution of this epic, the binary compatibility contraints from the global policy list is lifted.