Difference between revisions of "Frameworks/Epics/kdepimlibs"

Line 46: Line 46:
|- {{FrameworkTodo|kcalcore|Tier 2?|||}}
|- {{FrameworkTodo|kcalcore|Tier 2?|||}}
|- {{FrameworkTodo|kcalutils|Tier 2?|||}}
|- {{FrameworkTodo|kcalutils|Tier 2?|||}}
|- {{FrameworkTodo|kholidays|Tier 1||John Layt|Split and basic port, will be replaced later by OpenHolidays}}
|- {{FrameworkTodo|kholidays|Tier 1||John Layt|Split and basic port, will be replaced later by OpenHolidays. Will need internal copy of KCalendarSystem}}
|- {{FrameworkTodo|kimap|Tier 2?|||}}
|- {{FrameworkTodo|kimap|Tier 2?|||}}
|- {{FrameworkTodo|kioslave|Tier 2?|||}}
|- {{FrameworkTodo|kioslave|Tier 2?|||}}

Revision as of 13:08, 16 November 2013

kdepimlibs Splitting Epic


The KDE PIM community has outlined the following plan for splitting kdepimlibs into Frameworks libraries

  • Wait for the kdelibs split to be completed and the preview release to be made
  • A frameworks branch to be created in kdepimlibs and Qt5 / KF5 basic porting to be performed here mostly by the Frameworks team (old frameworks branch to be reviewed and deleted)
  • Once work is started here no more style fixes to be applied to Master
  • Code relying on qt3support and deprecated libraries will be removed as part of the porting
  • Once porting is completed then kdepimlibs will be spilt into separate frameworks
  • Once split the maintainers of each framework will take over work to make any API and code changes required
  • PIM Frameworks will be released as and when they are ready, we do not need to release them all at the same time
  • PIM Frameworks will be prioritised depending on usage, i.e. libraries needed by KDE Workspaces and Kolab should be released first
  • kdepim-runtime will be split between PIM Framework and kdepim


See the other Frameworks pages for the KDE Frameworks Policies, the kdelibs Split Policies and the Definition of Done .

The kdepimlibs specific policies are:

  • Modules that use qt3support are to be removed
  • Deprecated API is allowed to be removed
  • Source compatibility requirements are relaxed due to fewer clients, but major rewrites are discouraged. Instead port the old library and create a separate new library (e.g. KHolidays and QHolidays).
  • Most libraries will aim for Tier 2, but some may be able to target Tier 1.
  • The initial KF5 port may rely on kde4support to enable the port to be performed by non-experts, but no Framework released may rely on kde4support so the maintainer must remove all usage. In particular all KDateTime, KTimeZone and KLocale usage must be removed and the Qt replacements throughly tested for regressions and behaviour changes.

Existing frameworks

Status Framework Tier Porter Maintainer Comments
TODO akonadi Tier 2?
TODO cmake Tier 2?
TODO doc Tier 2?
TODO gpgme++ Tier 2?
TODO includes Tier 2?
TODO kabc Tier 2?
TODO kalarmcal Tier 2?
TODO kblog Tier 2?
TODO kcal Tier 2?
TODO kcalcore Tier 2?
TODO kcalutils Tier 2?
TODO kholidays Tier 1 John Layt Split and basic port, will be replaced later by OpenHolidays. Will need internal copy of KCalendarSystem
TODO kimap Tier 2?
TODO kioslave Tier 2?
TODO kldap Tier 2?
TODO kmbox Tier 2?
TODO kmime Tier 2?
TODO kontactinterface Tier 2?
TODO kpimidentities Tier 2?
TODO kpimtextedit Tier 2?
TODO kpimutils Tier 2?
TODO kresources Tier 2?
TODO ktnef Tier 2?
TODO kxmlrpcclient Tier 2?
TODO mailtransport Tier 2?
TODO microblog Tier 2?
TODO qgpgme Tier 2?
TODO syndication Tier 2?

This page was last edited on 16 November 2013, at 13:08. Content is available under Creative Commons License SA 4.0 unless otherwise noted.