> Thiago Macieira <thiago.macie...@intel.com> kirjoitti 8.5.2015 kello 22.33: > >> On Friday 08 May 2015 16:10:27 Hausmann Simon wrote: >> Hi, >> >> Compilation wise I agree, it's low effort. But the situation is different in >> Jira IMO. > > Can we declare the module in Deprecated state and keep bug compatibility with > previous versions? If people are using it to transition from Qt 4, it should > retain as much of Qt 4's behaviour as possible. That includes buggy behaviour > that applications have most likely already worked around. > > We should fix only security issues, severe crashes and any issue resulting > with > loading both Qt Quick 1 and 2 into memory.
If we keep the state of making almost no fixes, why would it matter if Qt Quick 1 is not included in the Qt 5.6? Those who need it can take it from the repository and use with their app, even if we do not include the module any more in the official release packages. The thing is that since the beginning of Qt 5 we have been constantly adding things and not removing the parts that are less used (and deprecated). Even though one might think it takes very little effort to keep things around, the aggregate effort is significant. There are many great new things and improvements we could bring into Qt, but now a lot of time goes into keeping old parts afloat. If someone needs to use an old module, why not do it with a Qt version that supports it? Same goes to platforms and compilers - it is not feasible to properly support all upcoming and old versions. Yours, Tuukka _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
