On Sun, May 22, 2011 at 8:56 AM, Stephen Kelly <steve...@gmail.com> wrote: > Thiago Macieira wrote: > >> On Saturday, 21 de May de 2011 08:52:52 Stephen Kelly wrote: >>> > Having a Qt 4.9 release is kind of hard in two accounts. First, any new >>> > API we introduce there must be a strict subset of what's in 5.0. There >>> > mustn't be in 4.9 anything new that isn't in 5.0. >>> >>> Why is that? Because Qt4Support or whatever will have to have all >>> features of 4.x? >> >> The only "Qt4Support" is called QtWidgets. >> >> The problem is the "mostly source compatible" guarantee. If 4.9 has >> features that 5.0 doesn't have, then it isn't "mostly source compatible". >> It also screws up "95% of the apps will just recompile". > > I remain skeptical that it will be that easy. 5.0 is opportunity to fix > broken APIs, and that might lead to lots of small paper-cut changes, or > bigger changes through opengov, like localization stuff etc. It might be an > idea for NQDF to put resources into porting some medium complexity KDE apps > when the time comes to see how easy it really is. > >> >>> > Second, the schedules. We'd very much like to get 5.0 out of the door, >>> > final release, one year from now. Considering it takes 10-11 months to >>> > make a Qt 4.x minor release and we still haven't done the 4.8 one, >>> > there is no room in the schedule for a 4.9 release. Even if there were, >>> > forcing >>> > the fact that 4.9 API must be in 5.0 too could derail the 5.0 schedule. >>> >>> I would see Qt 4.9 as something that could come after Qt5.0.0, but I was >>> assuming that 4.x doesn't have to be a strict subset. I know nothing >>> about kernels, but I think the linux 2.4 series is still maintained (I >>> don't know if it gets features) even though 2.6 is quite mature now. >>> >>> I can see division of development and marketting attention and release >>> effort being roadblocks for further Qt4 releases. >> >> I don't see how a 4.9.0 after 5.0.0 is possible. Unless we're talking >> about *backporting* Qt 5 features into Qt 4.x... > > I was not really talking about backporting, but just keeping the development > alive and the code useful. I agree that would lead to divergence from Qt5 > and that's probably not wanted. > > As it is, Qt 4.8 doesn't provide a lot of useful stuff for Qt4 as its two > biggest features are open governance and modularity. > > The modularity stuff is out of date if I've understood correctly as there is > to be a qtbase (?) in Qt5 with I guess most of QtCore and QtNetwork and some > of QtGui (QTextDocument is not done afaict so it will have to be somewhere). > So it will be different modularity anyway presumably. > > The open governance won't allow any feature development on Qt4 as there will > be no more feature releases from Qt4, so that's only useful for Qt5 too. > People interested in opengov are interested in it for getting features into > Qt, not for fixing some bug before the 4.8.3 release. > > There will need to be an adjustment period while people get used to opengov > as it materializes. There will be no time to implement features in Qt4, see > what works and what doesn't work and what needs to be adjusted, then learn > from that and do it better in Qt5. Instead, there's only try it in Qt 5.0 > and if it's not right the first time, it's in Qt5 already, so there it stays > anyway. I'd like to see a way to port to new Qt5 features in Qt4 before > porting to Qt5, i.e. separating API breaks from version number bumps. Think > python 2-3. Maybe I am talking about backporting after all... > > I might be just imagining issues where there are none. I guess some things > around opengov and Qt5 and particularly the NQDF plans for it still need to > become more clear to me. I can imagine the Qt 5.0 release date slipping, and > a useful (for KDE) release some time after that, leaving Qt4 cold for some > time, and I wonder what that means for KDE and other big users of Qt4, which > I expect to be slow to migrate until they see the benefits. Any new features > written for Qt5 can't be used (by KDE) for a few years practically, and as > there's no more features going into Qt4 either, I see a gap in motiviation > to contribute to Qt through opengov. > > In short, I'd like to see what opengov can do for the Qt4 series, maybe a > 4.9 release, and then rebase Qt5 on top of that before the 5.0 release. > > Sorry for rambling. > > Steve.
I'm going to have to agree with a lot of these sentiments. But in a nutshell, "mostly source compatible" I believe is anathema to having a 5.0 release. This is when you SHOULD be breaking source compatibility. This is where you should be dropping duplicate functions, fixing names that don't fit the proper style, and overall correcting the mistakes you couldn't fix in Qt4. Maybe it'll be mostly-source-compatible if you're talking about code written to work with 4.8 that doesn't use ANY functions marked as deprecated, but if we're talking about code that was written to work with Qt 4.5 or Qt 4.6... I would say that comprises more than 5% of the Qt4 code out there, and I would HATE to see Qt5 keep API problems around just to maintain Qt4 compatibility. /s/ Adam P.S. What's NQDF? My Google-fu is failing me. _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
