> -----Original Message----- > From: development-bounces+kai.koehne=digia....@qt-project.org > [...] > > Before merging a feature the maintainers consider if yes or not the > > feature is ready for integration. If bad decisions are made, I don't > > think the "time- based" releases have anything to do with that. > > It has to some degree, because it leads to rushing features in before the > deadline; and then API reviews, blatant bug fixes, writing examples, source > cleanups, etc. happen in stable after the merge (and not, as I said, before > even merging into dev).
The thing is, you can't get out any release of something as big as Qt without deadlines. And with deadlines comes the rush to get stuff in ... Actually that's even worse when it's pretty unclear when the next major version will be released, cause everybody knows that the original schedules aren't worth the paper they're written on, in the first place. We had that in Qt 4 times. I just checked, it took 15 months from the release of 4.7.0 until 4.8.0. We routinely did miss target dates by a couple of months. One of the results was that we crammed in features into patch level releases... [1] Maybe we do indeed take features in too lightly. And maybe we have to be more strict following up on new features to make sure that they're really polished & ready at release time. But for all of this, having a predictable schedule is IMO a necessary prerequisite. Regards Kai [1]: I know that Qt 4.7/4.8 were kind of special for various reasons, and that it wasn't all caused by the unpredictable schedule. But it definitely didn't help. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
