On Sunday 18 January 2015 04:07:02 Kevin Kofler wrote: > > - it was agreed upon in 2011 > > Fedora never agreed to the solution that was implemented. It clearly does > not fulfill our requirements. Never did, never will.
Unanimity was not required. Only consensus and that was achieved. The requests for renaming were argued and heard (I argued for them myself, I even prepared patches and had the solution in progress) but in the end the consensus was another way. Now everyone, including me, has to abide by that decision, unless there's new relevant information that didn't exist then. You haven't presented any new information. Therefore the solution stands. Fedora can choose to abide by the consensus that was formed or do whatever it chooses anyway. If you choose the latter, don't expect us to take your arguments into account in the future (we promise to listen, at least). > Keeping tool invocation compatibility for a new major version of a library, > which will definitely not be 100% source-compatible anyway (at the very > least, deprecated functions will be dropped), strikes me as a "feature" of > very limited usefulness. Well, evidence proves you wrong here. Qt Creator compiled for a LONG time with both Qt 4 and 5. Does it still? I'm not sure. It used both the "very limited usefulness" feature of Qt 5 being almost source compatible with Qt 4 as well as qmake's "very limited usefulness" solution too. If Qt Creator, complex as it is, can do it, simpler applications can too. Another example is Subsurface, the project I work on in my spare time (which isn't a lot). Only now are we considering dropping Qt 4 support. There were also quite a few people who reported very ease of porting to Qt 5. I remember even a few who ported "accidentally", when they ran the wrong qmake. > Programs will likely need some amount of adaptation to Qt 6 anyway (they > typically did for Qt 5) and so changing a hardcoded moc-qt5 (which they > should already be using rather than moc at this point – if they're still > using deprecated stuff, they'll need to get rid of that before porting to > Qt 6, this also goes for the code anyway) to trying both moc-qt6 and moc-qt5 > is going to be the least of the developer's worries. It's work they don't have to do -- death by a thousand paper cuts. Why should we make them change when it's within our grasp not to force that change? This was the argument that won the discussion over the not-renaming back in 2011-2012 and it's still valid today. Another argument is reducing the barrier of entry into Qt 5. For the rest of the arguments, please refer to the archives. Once again: I argued against it in 2011-2012, but you don't see me rebelling against that now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
