[Releasing] Deprecation - we are doing that wrong

[Rutledge Shawn]

> On 4 Feb 2016, at 09:15, Jędrzej Nowacki <jedrzej.nowacki at theqtcompany.com> wrote:
> I see a few options:
> A. we ask someone to maintain a deprecated / removed module, but then I guess 
> it would be better to change the status to Done.
> B. we can disable tests run on Qt5 for deprecated / removed modules. It would 
> allow us to make the release, but essentially a module would stay locked down 
> as it is now (currently you need to stage a few changes in one go to pass CI)
> C. we can disable tests completely for such modules. So we would assume that 
> if they compile then they are good enough. You know what are the consequences 
> of it.
> D. we can avoid shipping them completely
> 
> Pick your poison. I would take D but that is because of I'm in the mood of 
> cutting problems. C is probably fine too. B is just stinking compromise which 
> would fail soon (you need to fix a module to get build fixes...). A is beyond my 
> powers.

Probably QtQuick 1 could be in category D by now - it hasn’t been maintained for a long time.  Even before that it was on life support mainly because Creator needed it.  Whereas Webkit and QtScript are still too popular, even though we’d like to get rid of them, right?

QtQuick 2 has never had paint(QPainter*) methods on the Items, as in QQ1.  The only reasons I know of are that maybe it would be considered misleading - people would think the paint method was used for rendering normally, whereas it’s really not; and so that we could keep the 2D renderer separate and charge money for it.  But now the second reason has gone away, so if we make it easy to render a QtQuick 2 item tree the same way as in QQ1, then maybe people will not miss QQ1 anymore.

Besides, I need those paint methods to be able to work on QtQuick printing support later on.

About QtScript, we didn’t really finish replacing all its use cases with V4 yet, did we?  At least a while back, people were complaining that they still can’t switch.