El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va escriure: > On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: > > > * I'd consider Qt to be a lower level library. Qt mostly provides > > > fundamentals just like libc or the STL, > > > and it's therefore okay for me to just work with what I have available. > > > > I hope you can understand that the decision on how Qt (on one side) and > > KDE > > Frameworks (on the other side) should be released, does not only depend > > on the > > way *you* consider Qt and KF5. Other people have a different view on both > > (e.g. Qt developers do work on Qt, while app developers might treat KF5 > > as > > something "fundamental where they just work with what they have > > available). > > You want to draw a line somewhere, while others draw it elsewhere, and > > yet we > > have to make decisions that work for everyone, not just for you. > > I completely understand that. I'm searching for a solution that works > for everyone, and I'm pointing out that the current situation does not > work for me (as a maintainer of kimap that should become a framework, as > a KDE PIM developer and as kolab developer). > I only wanted to elaborate on why I can deal with the Qt situation, > but can't really with the one in frameworks.
I just want to point the obvious solution of "you don't need to make kimap a framework, you can just release it yourself and problem fixed" (not sure if anyone had before, it's a long thread :D) > > > > So for me each framework is an individual library, and > > > should be treated as such, > > > because I do want to work on the respective framework instead of running > > > in my own circles in wherever I use the framework. > > > I therefore need to be able to use the results of that work on all my > > > target platforms, otherwise working > > > on the framework is just having me implement the same thing twice. > > > > Making it possible for people to work on frameworks and then use the > > result in their applications quickly is exactly the reason why we have a > > monthly release cycle (unlike Qt). > > I'm trying to point out that this solution does not work for the > scenario I want to use certain (soon to be) frameworks, which is > deployed on a server in an enterprise environment. In these scenarios I > can't just tell to run the proverbial "yum update" to pull in as many > packages as I like. Either I manage to keep changes to a justifiable > minimum that we can be tested sufficiently, or I have to implement a > workaround. And implementing workarounds to use the real fixes a year > later once we actually get to upgrade all systems to the required > frameworks version is not a sustainable solution. > > > You can implement stuff in KF5 and use it the month > > that follows in the layers above. > > In an enterprise environment I simply can't. This works very well for > the developer on his bleeding edge machine, but in other cases just > doesn't. In an enterprise environment, you control everything, just cherry-pick the fixes you need, since we're assuming here you need exactly the bugfixes you want (since you know which versions to update and where, etc) > > > This is orthogonal to the discussion on version > > numbering, i.e. I definitely don't see this as an argument in favour of > > version hell. > > There are numerous reasons for me to advocate individual version numbers > per library that are controlled by the maintainer, but I don't see the > discussions as orthogonal: > * I need the version number as a tool as maintainer to do some release > engineering. > * Bumping version numbers and dependencies periodically doesn't work for > the enterprise usecase (due to random changes getting pulled in for an > otherwise trivial update). That's nothing to do with "bumping version numbers", and everything to do with the lack of a stable version, again as an enterprise, it's your task to "productize" the library if the library doesn't do everything you need. > * By removing the version number we remove a valuable communication tool > from the individual libraries. > > I appreciate all the work you're doing, and I'm certainly not trying to > make your life or anyone elses harder, but these are actual problems I'm > facing that I need to solve somehow, and that I think are solvable. But > it would help to get some more input on what the actual problems on your > end are other than some references to "version hell". If we can solve > the problems I'm also perfectly willing to do the work that is > necessary. > > Cheers, > Christian > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
