Am Thu, 31 Oct 2013 14:58:43 +0100 schrieb Kevin Krammer <kram...@kde.org>:
> 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. So it *is* possible with qt4 / kde4 already and not a feature (planned or already done) in qt5 / kde5. To convince other application developers to do the same, no idea how qt5 might help help there. As I guess the most obvious reason for slower paced development is just lack of manpower. Any pointers there that qt5 does actually help? > 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. Uh... even after reading that paragraph several times, I seem to have some issues understanding it. O_o So... come again? Or point me to the other mail, maybe that will clear things up. > > > 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 ;-) Yeah! :-) But it is kind of hard to make the balancing act between showing Duncan what parts *could* (or should) be skipped and carrying on the overall conversation. The idea was to show him a possible conclusion a person might have and as the reaction to that conclusion would miss the scope of the conversation, try to convince him to not answer it. But agreed, under normal circumstances I would not have written a thing that could be understood as a question when I don't want that question to be followed in the first place. But in this case the idea may have failed or was a bad idea to begin with... whatever. :-) > 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). As I don't want to go there any further anyway: We'll see. ;-) regards Michael ___________________________________________________ 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.