On Friday, 2013-03-22, Duncan wrote: > My problem isn't so much with that, it's with killing support for old > versions before the new versions are sufficiently stable replacements, > ESPECIALLY after promising support "as long as there are users!" That > triggered a drop of a lot of my former kde software choices with the bump > to kde4, when kde was insisting that kde4 was stable and that they > weren't supporting kde3 any longer, at the very SAME time they were > saying on bugs "Oh, that's not ported to kde4 yet." Well, the 3 series was actively released about one and a half year into the 4 series and continues to be available up to today. To make certain older version become unavailable would be a lot of work, requiring to remove tags, branches and time information from the repositories. I consider it an inherent bonus of openly developed software that any version is available at any time. Whether certain products are update to newer APIs mostly depends on human resources associated with the product. Both as in availability (e.g. people switching to other areas, leaving the community, etc) and in decision making (e.g. joining efforts with a similar product's team, finding that newer technology has obsoleted a product, etc). While this does of course impact ongoing maintenance, e.g. shifting from product creators to product distributors or deployers, it does usually not impact ongoing availability. The latter usually not only in the form of markers in source code repositories but also in the form of archived release packages, etc. > The story repeated > with the akonadification of kdepim; I honestly DID try the akonadified > kmail, but somewhere about the time it lost my 10th mail or so and I was > trying to figure out whether it got caught in akonadi somewhere or was > simply gone (after having to do much of the conversion manually in the > first place because the automated process failed), I asked myself why I > put up with it, why I couldn't just expect, AND HAVE, email that "just > worked", that devs didn't needlessly change something that was working > perfectly fine as it was, breaking it in the process. (Ironically, I > ended up on claws-mail, one of the "short list" of clients I had > evaluated but eventually dropped for kmail, back when I originally > switched from MS and OE. It's still using the same mh-dir mail format it > was back in 2001... and it still works. Only unlike kmail, they didn't > drop a well working solution in a chase for utopia. Had I only chosen it > back then...) One of the things that can easily be missed when not considering the surroundings of the "big picture" is that requirements for products of the same or similar category can be vastly different. Akonadi is certainly a bit overengineered, also due to it being the second generation solution (second generation problem), but it does address needs and issues gathered over years of wide spread use. For example, if we look at KMail, one can easily fall into the trap of thinking of it as just an program for writing and reading emails and thus compare it too closely with other products that do that but only that. However, if one considers the additional requirements, it becomes often quickly obvious that other product's features for those requirements are either quite crude or not existant at all. Lets for example take the basic requirement of enabling other programs to send email, e.g. need for sending out invitations to events in scheduling and calendaring applications. While working on xdg-email it became often quite frustrating that email programs would either not have stable external interfaces (commandline, D-Bus or otherwise) or not even have them at all! Another, often quite problematic use case, is providing access to the addressbook or being able to access an externally provided one. A lot of programs fail to have accessors for external addressbooks, are only able to deal with their native one or are rather fragile regarding concurrent access (e.g. not having (proper) file locking or assuming in-memory state is equal to on-disk state, etc). Even for KMail, which had those requirments covered for quite some time already, some choices on how to do them had massiv impact on the agility of the product, its maintainablity and so on. The solution the involved developers devised deals with those requirements in an architecturally clean way. Unfortunately implementation of even the cleanest architecture and design can be difficult and appear to be complete and stable under test conditions because, e.g. some cases of data or configuration have just been hit yet. Due to the availability of alternatives, including previous versions of the same product, these growing pains can often be mitigated for certain groups of users, e.g. those not needing any advanced features or those who can live with the quirks of previous versions. > Fortunately, kde5 aka kde frameworks is supposed to be a much less > disruptive upgrade, and it's going much more modular as well, so it's > much less likely. But THIS time I'm prepared, should it happen. I won't > be caught not viably being able to switch, again. Indeed. Frameworks 5, aside from its modularization work, will also improve the visibility of the distinction between different products. Discussions like this are a good example how difficult it still is for many people to see the how wide the range of products is, how unrelated certain products and their respective teams are to others, etc. > Of course there's the possible upcoming xorg -> wayland switch to worry > about too. That could really upset the Linux desktop environment status > quo in all sorts of interesting ways and I think most of the leading DEs > realize that. My guess would be that only a small group of products will be affected, mostly those related to the workspace category, maybe some system tools. The vast majority of programs does not employ any X11 specific code and should thus be mostly unaffected by a move away from it. The main unforseeable issues would be hidden assumptions on system behavior. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
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.
