On Thursday, 2013-10-31, 11:45:04, Michael wrote: > Am Tue, 29 Oct 2013 14:35:29 +0000 (UTC) > schrieb Duncan <1i5t5.dun...@cox.net>:
> > Up the stack at the application level, kde5 is breaking up and > > shipping most individual apps with their own version tagging and > > release timing, so apps that are evolving fast can ship updates every > > month or even every week if they wish, while already mature apps in > > primarily maintenance mode might ship an update a year, mostly just > > to keep them building on current libraries with current tools, with > > the occasional security update as well when necessary. > > With QT4 / KDE4, could applications not just build against maybe older > qt- / kdelibs which would then not prevent fast-paced > application-development? There are already quite some applications that have their own pace, e.g. Amarok and Digikam, so this is mostly an option that might be explored by more applicatons in the future. The relation to the KDE Frameworks 5 initiative is that are consideration to potentially release frameworks separately or in smaller groups on individual schedules. When the release of dependencies is no longer synchronized, it becomes more unlikely that things built upon them are released in a synchronized fashion. But, as I said in another posting, this is not definit yet. > > That means currently qt-but-non-kde apps and desktop options may > > become more popular as well. There's smplayer, and the razor-qt > > desktop. > > Right, there *is*! No idea why the new "de-coupling style" benefits > such projects. BUT ignore the question you might see here, as it will > go in a direction which is out of the scope of this thread. Really, > don't answer the question, ignore it. Should probably not ask it then ;-) It is somewhat relevant though. Making KDE technology more available to projects currently not using it has the potential of increasing the number of people working on them. Another thing that influences the topic of QA is that part of the effort is to increase test coverage, or, making the tests more explicit (things that got lots of implicit testing through being used by other parts now gain their own tests). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
