[Development] Suggestion on QML portability

[Robin Burchell]

On Mon, Jul 16, 2012 at 2:02 AM, Alan Alpert <alan.alpert at 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