Applications Lifecycle Policy

[Harald Sitter]

On Tue, Jul 4, 2017 at 11:16 PM, Luigi Toscano <luigi.toscano at tiscali.it> wrote:
> That sound fine, with one caveat: without having the 4 entities in separate
> nodes of the graph we can't describe the transition between modules. You wrote
> that this would "ease transitioning", but I think that we may want to capture
> for example the transition from "any" to Frameworks, which has specific rules.
> And so on.

The node removal was specifically about extragear I think. That being
said, I think it's fair to say that differentiating the frameworks and
plasma nodes from applications should be done and is in fact
necessary.

Frameworks and Plasma are different from Applications.

Frameworks have ABI stability requirements + the metainfo.yaml thing +
before becoming a framework you have to pass an additional checklist.

Plasma as a whole is governed by the plasma team with the expectation
that every application has a purpose and furthers the agenda of plasma
(or that's how I'd describe it anyway ;))

Applications are a mixed bag, but with the disappearance of the
software-collection notion, a fairly liberal mixed bag as there is no
longer the expectation that these are applications for plasma. Rather,
they are applications by KDE, which happen to work very well with
plasma. Your software needs to pass kdereview to pass baseline quality
requirements (and afterwards continue to build ;)) but beyond that I'd
say the applications component is the wild west (in a good way). As
such the previous wild west known as extragear has been reduced to an
unfortunately named weird side-branch without clear purpose or
difference to applications.

Switching to frameworks or plasma, to me at least, seem like making an
additional commitment. Switching between applications and extragear is
only a matter of being inside the release schedule or outside.

HS