For the specific case of QtQuick1, I'd say that closing any issues that aren't applicable to QtQuick2 (or won't be done) with a useful message explaining the situation makes sense. It might also make sense to close reporting of new issues for that component.
On Fri, May 8, 2015, at 06:10 PM, Hausmann Simon wrote: > Hi, > > Compilation wise I agree, it's low effort. But the situation is different > in Jira IMO. > > > Simon > > Original Message > From: Thiago Macieira > Sent: Friday, May 8, 2015 17:37 > To: [email protected] > Subject: Re: [Development] Future of Qt Quick 1 in Qt 5 > > > On Friday 08 May 2015 14:39:38 Frederik Gladhorn wrote: > > Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing > > this email), I feel confident that the time has come to move everyone over. > > For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer > > as backend. > > (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/) > > > > In short, is there any reason not to remove Qt Quick 1 from Qt 5.6? > > Do we need to do anything at all? How much effort is keeping Qt Quick 1 > compiling these days? We're not doing anything besides that, are we? > -- > 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 > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
