On Mon, Jul 16, 2012 at 2:02 AM, Alan Alpert <alan.alp...@nokia.com> wrote: > The theory is that you're not trying to maintain a single codebase for both > QML1 and QML2.
The point has been made before, but I'll repeat it: for libraries and other pieces of middleware, that isn't really an acceptable answer. As a library author, I guarentee that you will get pushback, resistance, and hostility from insta-deprecating one release the moment you make another. Just like, for instance, Qt users would raise merry hell if we dropped Qt 4.8 at the same time as we released Qt 5. Now, that doesn't mean that it isn't possible to release based on two seperate codebases, but, the QML is more or less identical. So what does that gain me except a major pain in the ass in terms of making sure I merge branches, often? And that's assuming that all contributors are "well behaved" enough to remember that their contributions must go on both branches, etc, etc, etc. I do understand that this isn't an easy problem at all, but when the price to pay is just marking some methods as deprecated - as opposed to completely removing them - isn't this a manageable pain in the name of "making things easy" for middleware authors? And after all, isn't one of the promises of Qt 5 that we have source compatibility mostly intact? > Perhaps we just gave up because the significant behavioural > differences guaranteed that it would be a major pain no matter what. Renaming methods is not a behavioural difference. > But I don't understand why MeeGo components need to have a unified branch, > surely the > first version using Qt5 uses QML2, the previous version uses QML1, and they > have to be on separate branches anyways? You're assuming that there's a complete cutoff. That isn't the case for most middleware, and while it could be for our intended uses of components, it would hamper our ability to get things done: we'd have to port every QML application we have to QML2 instead of just doing them one at a time, as we please. And that also then means that every third party application using QML is forced to be QML2-only, likewise. That's not really acceptable given that the majority of MeeGo applications are QML1, and developed by a whole swarm of people. >> Is there really that much pain in having a deprecated >> closeSoftwareInputPanel method so I don't have to resort to somehow >> preprocessing the QML, for instance? > > Yes, there is that much pain. At least that's my interpretation from the > example of Qt3Support. When do deprecated methods get discarded, if not across > major versions? Ah, perhaps here is where we misunderstand each other. Can you point out when these were deprecated? Because they certainly weren't in 4.8[1], and there's no replacement for them there. Otherwise I wouldn't be complaining. My point is that they should have been deprecated first, at least until QML 2.1 or something, allowing one release of overlap (6-12 months) at least is probably sufficient for people to migrate given that QML is still a fast-moving, fast-developing technology. thanks, Robin 1: http://doc-snapshot.qt-project.org/4.8/qml-textinput.html#closeSoftwareInputPanel-method _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
