Eine eher unbefriedigende Antwort findet sich in den release notes:
To avoid confusion KDE Applications has been debranded to be KDE's release service.
Ich lese das so, dass diese Sammlung in Zukunft quasi namenslos erscheint.
2.
Im übrigen diente der Name dazu, sie vom Framework und von Plasma zu unterscheiden.
Nach Punkt 1 unterscheidet er sich im Grunde genommen ja weiterhin, oder? Etwas mit einem Namen unterscheidet sich von einer namenlosen Sache durch deren Namenlosigkeit.
Damit Sie mich nicht falsch verstehen: Für verbesserungswürdig halte ich die Situation allemal'.
3.
Dass Anwendungen Plugins benutzen und auch Bibliotheken benötigen dürfte immer klar gewesen sein.
Naja, bei Bibliotheken lässt sich da streiten, finde ich. Erstmal führt das zu unnötiger Verwirrung, denn idealerweise sollten die in den Frameworks sein.
Mir würden sich da folgende Fragen aufdrängen: Aber warum sind Sie das im Einzelfall nicht? Mangel an Qualität oder Pflege? Waren/sind die Applications in Anlehnung an die Nomenklatur der Linux-Entwicklung so eine Art staging area mit Quellcode minderer Qualität? Wie kann sich ein professionelles Projekt es leisten, das Risiko eingehen, dieses Potential des suggerierten Missverständnisses beizubehalten?
Bibliotheken, die Teil von KDE Frameworks sind, müssen ABI-kompatibel bleiben bis KF6. Und dann wieder bis KF7.
Gerade neue Bibliotheken haben nicht von Beginn an die perfekte API, oder sie bekommen neue Nutzer, für die sich andere API-Design-Konzepte lohnen. Da will man dann zügig eine neue major-Version der Bibliotheken machen können, die mit der alten API bricht. Geht aber nicht, wenn man Teil der KDE Frameworks ist.
Oft sind es auch Bibliotheken, die aus einer App heraus entstanden sind, aber bislang noch keine weiteren Nutzer gefunden haben, und daher fürs Erste eng zusammen mit der App entwickelt werden, ohne Rücksicht auf ABI nehmen zu müssen, bis dann irgendwann andere Interesse zeigen.
1.
Eine eher unbefriedigende Antwort findet sich in den release notes:Ich lese das so, dass diese Sammlung in Zukunft quasi namenslos erscheint.2.
Nach Punkt 1 unterscheidet er sich im Grunde genommen ja weiterhin, oder? Etwas mit einem Namen unterscheidet sich von einer namenlosen Sache durch deren Namenlosigkeit.Damit Sie mich nicht falsch verstehen: Für verbesserungswürdig halte ich die Situation allemal'.
3.
Naja, bei Bibliotheken lässt sich da streiten, finde ich. Erstmal führt das zu unnötiger Verwirrung, denn idealerweise sollten die in den Frameworks sein.Mir würden sich da folgende Fragen aufdrängen: Aber warum sind Sie das im Einzelfall nicht? Mangel an Qualität oder Pflege? Waren/sind die Applications in Anlehnung an die Nomenklatur der Linux-Entwicklung so eine Art staging area mit Quellcode minderer Qualität? Wie kann sich ein professionelles Projekt es leisten, das Risiko eingehen, dieses Potential des suggerierten Missverständnisses beizubehalten?
Bibliotheken, die Teil von KDE Frameworks sind, müssen ABI-kompatibel bleiben bis KF6. Und dann wieder bis KF7.
Gerade neue Bibliotheken haben nicht von Beginn an die perfekte API, oder sie bekommen neue Nutzer, für die sich andere API-Design-Konzepte lohnen. Da will man dann zügig eine neue major-Version der Bibliotheken machen können, die mit der alten API bricht. Geht aber nicht, wenn man Teil der KDE Frameworks ist.
Oft sind es auch Bibliotheken, die aus einer App heraus entstanden sind, aber bislang noch keine weiteren Nutzer gefunden haben, und daher fürs Erste eng zusammen mit der App entwickelt werden, ohne Rücksicht auf ABI nehmen zu müssen, bis dann irgendwann andere Interesse zeigen.
Das wäre ein wesentlicher Grund.