Frameworks/Terminology: Difference between revisions
No edit summary |
(Add terminology for KDE4Attic taken from IRC conversation with ervin) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 11: | Line 11: | ||
A Framework is the base unit of KDE Frameworks. It is a self contained body of reusable code. It can consist of a single library in its simplest form, but it can grow to being several libraries and a few shipped plugins. A Framework is generally shipped also with tests, demos and examples. | A Framework is the base unit of KDE Frameworks. It is a self contained body of reusable code. It can consist of a single library in its simplest form, but it can grow to being several libraries and a few shipped plugins. A Framework is generally shipped also with tests, demos and examples. | ||
Frameworks are classified along two axis: Tier and Type. This classification provides constraints on the outside dependencies of a Framework. For more details, see the [[Frameworks/Policies|Policies]] page. | Frameworks are classified along two axis: Tier and Type. This classification provides constraints on the outside dependencies of a Framework. For more details, see the [[Frameworks/Policies#Frameworks_have_a_Tier_and_a_Type|Policies]] page. | ||
== Platform 11 == | == Platform 11 == | ||
[[KDE_Core/Platform_11|Platform 11] | |||
[[KDE_Core/Platform_11|Platform 11]] is the meeting which resulted in the creation of KDE Frameworks. It's been held in 2011 in [[Sprints/Randa| Randa]] to work out a plan for kdelibs. The decisions taken there impacted how we structure our libraries, how to distribute our runtime bits and how we deal with our upstreams and downstreams. Because of those radical changes, the decision was taken to create a "KDE Frameworks" product (although it's mainly based on the existing kdelibs and accompanying runtime parts). | |||
==KDE4Attic== | |||
Stuff which shouldn't be deprecated, but we treat as deprecated for the time being. i.e Ideally would form part of Qt but is unlikely to in the near future except if someone puts the work in to Qt. | |||
Latest revision as of 15:35, 14 May 2013
The people working on KDE Frameworks use some terms you might not find in other KDE teams. This page is listing and defining them.
Epic
This term comes of the agile movement. There people generally plan using user stories which are splitted in tasks. A group of story can form a feature, and then features would group in epics.
So in other word, an "Epic" is a very large body of work encompassing several different activities. It is comparable in size with a project in the traditional meaning (an effort of several months which has a start and an end).
Framework
A Framework is the base unit of KDE Frameworks. It is a self contained body of reusable code. It can consist of a single library in its simplest form, but it can grow to being several libraries and a few shipped plugins. A Framework is generally shipped also with tests, demos and examples.
Frameworks are classified along two axis: Tier and Type. This classification provides constraints on the outside dependencies of a Framework. For more details, see the Policies page.
Platform 11
Platform 11 is the meeting which resulted in the creation of KDE Frameworks. It's been held in 2011 in Randa to work out a plan for kdelibs. The decisions taken there impacted how we structure our libraries, how to distribute our runtime bits and how we deal with our upstreams and downstreams. Because of those radical changes, the decision was taken to create a "KDE Frameworks" product (although it's mainly based on the existing kdelibs and accompanying runtime parts).
KDE4Attic
Stuff which shouldn't be deprecated, but we treat as deprecated for the time being. i.e Ideally would form part of Qt but is unlikely to in the near future except if someone puts the work in to Qt.