[Development] Feature freeze date?

Thiago Macieira thiago.macieira at intel.com
Wed Dec 14 18:42:49 CET 2011


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
> 
> 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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111214/af9e035a/attachment.sig>


More information about the Development mailing list