On 5 May 2017, at 13:15, Konstantin Tokarev <annu...@yandex.ru<mailto:annu...@yandex.ru>> wrote:
05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io<mailto:tuukka.turu...@qt.io>>: Hi, There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync. I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently. For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary. BTW, let me bring an attention to the elephant in the room. Yes, my fork of QtWebKit existed for a while as a separate item. But it was never and "official" successor, and even me myself was warning people that it is not an official replacement as some features are not yet restored. However, now there is no valid reason to keep using QtWebKit contained in 5.9 and dev branches anymore. Feature parity is achieved to the level of drop-in replacement that can be applied system-wide. Still many people see 5.9 branch as a source of truth. Yes, we have been keeping the old code compiling, but we have not been supporting it for a while, and it hasn’t been tested since then neither. We need to convey a message to wide audience that old QtWebKit should no longer be used, and that there is a new release that should be used instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). I agree here. We’ve kept the old Qt Webkit compiling against newer Qt version because of requests from the community. I think we can drop this now, and tell people to use your branch instead. It’ll certainly be better and safer than the old code base. This is why question about version numbers and related stuff is important. If this is not done, it doesn't matter at all whatever tag names will be picked and what schedules will be followed. I have no problems dropping the old qtwebkit code base and tell people to move over to use your branch. One option is that we do not provide any source package from the old code base for qtwebkit with Qt 5.9 anymore. This would free up the version numbers from 5.9 onwards. At the same time I do agree with Tuukka, that we need to reconsider the coupling between webkit/webengine and Qt releases. if current QtWebkit runs nicely on top of Qt, maybe that’s how we should keep it. This would allow us to provide source/binary packages of it on a more independent schedule. Cheers, Lars Yours, Tuukka On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" <development-bounces+tuukka.turunen=qt...@qt-project.org<mailto:development-bounces+tuukka.turunen=qt...@qt-project.org> on behalf of annu...@yandex.ru<mailto:annu...@yandex.ru>> wrote: 04.05.2017, 19:35, "Oswald Buddenhagen" <oswald.buddenha...@qt.io<mailto:oswald.buddenha...@qt.io>>: > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote: >> 03.05.2017, 17:27, "Sergio Martins" <sergio.mart...@kdab.com<mailto:sergio.mart...@kdab.com>>: >> > On 2017-05-03 15:02, Konstantin Tokarev wrote: >> >> Remaining question is versioning. While it's fine to dub current >> >> release "5.9" (but not 5.0, because we will have another WebKit update >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides: >> >> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, >> >> or is updated >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from >> >> 5.2 as of now), and can be used e.g. as security update in Linux >> >> distro that does not normally update Qt version during its life cycle. >> >> >> >> Any comments? >> > >> > If Qt and QtWebKit will have different release schedules then that >> > numbering would indeed confuse people. >> >> What about choice of new versioning scheme? >> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it >> clear that versioning is different now. Bug fixes will increment patch version (6.0.x), >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major >> verison (7.0 etc.) >> >> Qt5 supermodule will be tracking latest available stable branch. When release branch >> is created (e.g. 5.10.0), corresponding patch release branch is created in qtwebkit >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release branches. >> >> However, I'm not sure about two things: >> 1) Is it possible to have custom branch names in qtwebkit repository, or there need to >> be virtual 5.10 etc. branches to match other modules? >> 2) What about bug tracking in JIRA? I would like to keep existing issues as is, but assing >> new release numbers to items fixed in new releases > > i'll say outright that you can't be part of the qt supermodule and yet > have independent releases. while that was the plan once upon a time, the > whole release infrastructure simply doesn't deliver, and even just > diverging branch names are a pita (proved by enginio). as a product, qt > is as monolithic as ever. Understood: no custom branch/tag names in official repo. > > your release cycle concerns seem to be centered around the webkit > backend, and you can deal with that by lowering the compatibility > guarantees of patch releases at this level, i.e. take the freedom to > upgrade webkit in a patch release. as long as you keep qt's api/abi > compat promises, you're fine. that means that you will not be able to > expose new webkit features until the next minor release if they require > new api. That's probably fine with me, except 2 moments that seem to require "out of band" releases: 1. Something should be done with current release. As I said, it's not an option to postpone it to 5.10, however it also cannot be released as 5.9.1 because there are API additions which I don't want to revert (in particular because these APIs were already shipped by Linux distros that chose to provide TP4 and TP5). Also there is a change in QDataStream format of QWebHistory. 2. Security updates. WebKitGTK team provides several patch releases for each stable branch, which contain only fixes for bugs and security issues, and towards the end of release life cycle they became primarily security updates. I think we should be able to release such updates ASAP, by making up some tag name and scheduling custom build against newest patch release of Qt. > _______________________________________________ > Development mailing list > Development@qt-project.org<mailto:Development@qt-project.org> > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org<mailto: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
