[Releasing] Deprecation - we are doing that wrong

Jędrzej Nowacki jedrzej.nowacki at theqtcompany.com
Thu Feb 4 11:12:36 CET 2016


On Thursday 04 of February 2016 09:23:12 Rutledge Shawn wrote:
> > 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.
 
As I wrote before technologies are changing and therefore use cases are 
changing too. I do not believe that we as Qt project need to keep feature 
parity forever for everything (QtScript case). Anyway my mail was not about if 
we should deprecate these modules, but what kind of level of quarantines are 
we giving for them. We already decided that we do not want to invest into 
them, but it seems that it is just a wishful thinking. It seems that with the 
current setup we need to compile and test them, which is  essentially what we 
are doing for Done modules.

Cheers,
 Jędrek






More information about the Releasing mailing list