On 12/14/2011 06:42 PM, ext Thiago Macieira wrote: > On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote: >> Ok, well let's start the list: >> >> https://wiki.qt-project.org/5.0_Feature_Requirements
my addition for network (feel free to point out more): == Network == * SSL errors (+ OCSP etc.): make it possible to display SSL errors without stalling QNetworkAccessManager (http://bugreports.qt.nokia.com/browse/QTBUG-19032) * Authentication: make it possible to display authentication dialog without stalling QNetworkAccessManager (https://bugreports.qt.nokia.com/browse/QTBUG-16251); this is obviously closely tied to above task * remove QHttp (https://bugreports.qt.nokia.com/browse/QTBUG-22750) * rewrite cookie jar (https://bugreports.qt.nokia.com/browse/QTBUG-23145) Peter >> >> One thing we could do is: >> >> 1. Let people populate the list >> 2. Review the list for plausibility in a reasonable timeframe >> and personal availability. >> 3. Estimate the time for the responsible people to get the work done. >> 4. Schedule feature freeze based on that. >> 5. Features that unfortunately don't get finished by then don't make >> it into 5.0, and possibly .x. >> >> That's just an idea of how to make progress though. Making a scheduling >> decision without any idea of what needs to be done in that timeframe doesn't >> really make sense. > > That's why I started the thread. We need to know what we need to do so we can > make a scheduling decision. Or, alternatively, we need to decide what we can > do given the schedule. > > I also oppose to your item #5 above. I don't want to see anything on a page > called "5.0 requirements" that can be postponed. I want *only* the stuff that > *must* go into 5.0, i.e., what cannot go into 5.1 or a later release until > 6.0. > > If we reach the feature freeze date and a requirement isn't complete yet, > we'll need to make a call whether to delay the freeze or not. This is > something we'll do only for 5.0, as for any future releases, anything can be > postponed. That also means we don't have "feature requirements", but only a > wish-list. [That's between us developers; in public communication we may call > them differently] > > For those things that can be postponed, we should have a separate roadmap > page. We can also start collecting ideas for future releases. > >>>> Backward incompatible change freeze? >>>> (Yes) >>> >>> See above on both SIC and BIC changes. >> >> Right. This would be soft-frozen probably at RC or beta time. > > Depending on whether you referred to source or binary incompatible changes; > and for the source ones, it's understood it applies to new features only. > >>> Of the "I can't judge" QtWidgets features above, considering that module >>> is >>> in Done state and we have a source-compatible requirement for 5.0 for >>> existing features, I would wager that they are not Qt 5.0 requirements. >> >> Yes, but there are also lessons which we need to ensure are not forgotten so >> that we have useful API for QML. An example is the QCompletion stuff. Doing >> that 'properly' and in a future-proof, QML compatible way probably actually >> depends on itemmodels getting new features, such as a virtual search() >> method to supercede the match() method. That's just an example. There may >> be others. > > I agree. However, we'll never finish finding new requirements or need to > improve > the API, so we need to make a cut somewhere based on our best understanding. I > might be an optimist here, but I'd have expected all these studies where we > need new API to have completed by now. We're 5 months into the 5.0 cycle, 1 > year into the QtDeclarative API, 6½ years since ItemViews and the rest of the > Qt 4 API. > > > > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development