From jani.heikkinen at qt.io Thu Nov 3 07:03:12 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 3 Nov 2016 06:03:12 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 1.11..2016 Message-ID: Meeting minutes from Qt Release Team meeting 1st November 2016 Qt 5.8.0 Beta: - Qt 5.8.0 beta packages under testing o All known blockers should be fixed in these packages - These packages will be released as Qt 5.8.0 Beta (if no new blockers found during package testing) o Target still during this week Qt 5.7.1 status: - No final packages available yet o Fix for one blocker still missing (QTBUG-56746) o Some important change files (https://codereview.qt-project.org/#/q/branch:5.7.1+message:%22Add+changes+file+for+5.7.1%22,n,z) missing Next meeting Tue 8th Nov 16:00 CET br, Jani irc log below: [17:00:25] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:50] jaheikki3: pong [17:02:13] Time to start qt release team meeting [17:02:19] On agenda today: [17:02:30] Qt 5.8.0 beta status [17:02:37] Qt 5.7.1 status [17:02:46] Any additional item to the agenda? [17:03:09] jaheikki3: pong [17:03:20] iieklund: pong [17:04:06] Let's start from Qt 5.8.0 beta status: [17:04:20] Qt 5.8.0 beta packages under testing [17:04:43] RTA smoke is OK, manual testing and full RTA ongoing [17:04:58] All known blockers should be fixed in these packages [17:05:51] Unfortunately iOS packages still missing, some weird timestamp issue is blocking us to create iOS installer package [17:06:15] Study ongoing but root cause not known yet [17:06:21] fix is under testing for that [17:06:34] great! hoping it helps... [17:07:33] I propose we release latest packages as Qt 5.8.0 beta when iOS package is done as well and if there isn't any new blockers found during package testing [17:08:38] +1 [17:08:43] +1 [17:08:56] Great! Target is get release out still during this week but let's see if we can get things ready early enough... [17:09:21] Then Qt 5.7.1 status: [17:09:47] qt5.git integration succeed this morning. [17:09:59] Exporting binary and src packages ongoing [17:10:50] target to create new set of installers for RTA testing today/tomorrow but no target to execute manual test round for these packages [17:12:16] Because these cannot be final Qt 5.7.1 packages: Fix for one blocker still missing (QTBUG-56746) as well as some important change files (https://codereview.qt-project.org/#/q/branch:5.7.1+message:%22Add+changes+file+for+5.7.1%22,n,z) [17:12:39] Any comments / questions? [17:14:38] Ok, I think it was all at this time [17:14:58] Let's have next meeting tue 8th Nov as planned [17:15:11] Thanks for your participation, bye! [17:15:18] bye! [17:16:48] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Mon Nov 7 15:57:23 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 7 Nov 2016 14:57:23 +0000 Subject: [Releasing] Qt 5.8.0 API review In-Reply-To: References: , , , , Message-ID: With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. From mitya57 at gmail.com Wed Nov 9 18:09:12 2016 From: mitya57 at gmail.com (Dmitry Shachnev) Date: Wed, 9 Nov 2016 20:09:12 +0300 Subject: [Releasing] Doing a new release of qtstyleplugins? Message-ID: <20161109170912.vn7pivk2bhytaqnq@mitya57.me> Dear release team, In Qt 5.7, the GTK+ style has been moved from qtbase to qtstyleplugins [1]. However, the last released tarball of qtstyleplugins [2] is from 2014, and does not include that style yet. Can someone please generate a new tarball for the latest qtstyleplugin code and update the page linked above? For me any version number would work, and I can wait a bit in case you want that release to be synchronized with Qt 5.7.1. [1]: https://code.qt.io/cgit/qt/qtstyleplugins.git [2]: http://download.qt.io/community_releases/additional_qt_src_pkgs/ -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From jani.heikkinen at qt.io Thu Nov 10 13:38:41 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 10 Nov 2016 12:38:41 +0000 Subject: [Releasing] Change file process & improvement proposal In-Reply-To: References: Message-ID: Hi all, Lately it has been quite hard to get change files done for the releases. It should be maintainers responsibility to make sure those will be done for every release and those are containing proper data. We have tried to help maintainers by doing initial ones for them (running script to collect all changes containing [ChangeLog] -tag). Unfortunately it seems that tag is really rarely used (at least in most of modules) even there is lots of changes in:( In my opinion (almost) all changes in patch level release should be worth of change file entry: If change isn't critical enough for change file entry does it belong in patch level release at all? Could we change our template/sanitybot so that it encourage developers to add change file entries more often and forces them to do it in release branches? One unclear issue related to change files is when we should have one? Should we create one only if there really is some critical changes in the submodule or should we create one in any case? I think the latter one could be more clear one: In first case it is unclear why one is missing? Is it because maintainer hasn't done his job or just because there isn't important changes to be mentioned? In latter case there is that change file for every release and it contains info if there is important changes or not. And another issue is the 'base release' for change files. Someones seems to think change files should contain diff from previous official release (meaning 5.7.1 change files should contain delta from 5.6.2) and others that diff should be from previous release of same series (meaning 5.7.1 change files should contain delta from 5.7.0). I have thought it is latter one and created initial ones based on that assumption. So I propose: 1) Let's enable [ChangeLog] -tag by default in commit template. After that you must remove/comment out it by purpose if you don't want add it. And in addition to this update sanity bot so that it will give '-1' if change log entry isn't given in release branch. This can be bypassed by giving '+1' manually for sanity review if really needed... That way we could get more ready change files directly by running script and so on less work for maintainer. 2) Let's agree every submodule in the release needs to have a change file (to make things clear) 3) Let's agree the change log is the diff between new & previous release in same series (in case of patch level release, meaning delta from x.y.z -> x.y.z+1). And for new major release the diff is from last patch release from previous series Jani Heikkinen Release Manager The Qt Company From oswald.buddenhagen at qt.io Thu Nov 10 15:23:06 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 10 Nov 2016 15:23:06 +0100 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: Message-ID: <20161110142306.GC9877@troll08> On Thu, Nov 10, 2016 at 12:38:41PM +0000, Jani Heikkinen wrote: > Lately it has been quite hard to get change files done for the releases. > oh, it's that time of the year again. :D > 1) Let's enable [ChangeLog] -tag by default in commit template. After > that you must remove/comment out it by purpose if you don't want add > it. > i really don't think this will make a positive difference. the problem is that many people just don't have the right audience-oriented mindset. we *already* have lots of garbage changelog entries, and this will just worsen the S/N ratio. > And in addition to this update sanity bot so that it will give '-1' if > change log entry isn't given in release branch. > this is probably not sensible. most last-minute fixes relate to recently introduced problems, which means that they specifically *don't* need changelog entries. here's what i think would actually make a difference (based on historical evidence within trolltech): https://bugreports.qt.io/browse/QTQAINFRA-933 > 2) Let's agree every submodule in the release needs to have a change > file (to make things clear) > yes > 3) Let's agree the change log is the diff between new & previous > release in same series (in case of patch level release, meaning delta > from x.y.z -> x.y.z+1). And for new major release the diff is from > last patch release from previous series > that seems a no-brainer to me. the tricky question is what to do with LTS vs. stable, but we already resolved this: we duplicate the relevant log entries. From edward.welbourne at qt.io Fri Nov 11 11:14:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 11 Nov 2016 10:14:26 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <20161110142306.GC9877@troll08> References: , <20161110142306.GC9877@troll08> Message-ID: On Thu, Nov 10, 2016 at 12:38:41PM +0000, Jani Heikkinen wrote: >> Lately it has been quite hard to get change files done for the releases. and Ossi replied: > oh, it's that time of the year again. :D Speaking of which, it's also hard to get API reviews done, even though they are now much easier (because they get represented properly as gerrit reviews that show the change properly). See recent mail: of 17 modules with API reviews, one has a +2 and one a +1 on the latest PS; one has +1 on the previous; two are new reviews (I may have lost an earlier review) with no comments; three have comments on earlier PSs; qtwebengine's team concocted a better review (that's rather out of date) and have reviewed it; qtserialbus's maintainers note the need for a full API review; but seven add-on modules have had no comments. (Three of these were new in 5.7; the rest have been add-ons since at least 5.6.) Gerrit's diffs between patch sets work for you here: if you've reviewed an earlier patch set, you can review the change since in the usual useful way. No rebasing has happened. Please review (changelogs and) changes to your module APIs, Eddy. From jani.heikkinen at qt.io Mon Nov 14 09:44:08 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 14 Nov 2016 08:44:08 +0000 Subject: [Releasing] Qt 5.8.0 API review In-Reply-To: References: , , , , , Message-ID: Hi all, It seems this is still badly ongoing, only few '+1' and only one '+2' there :( Please try to finalize the review during this week: We need to have reviews done & possible changes in '5.8' before we can start branching from '5.8' to '5.8.0' br, Jani ________________________________________ From: Edward Welbourne Sent: Monday, November 7, 2016 4:57 PM To: releasing at qt-project.org Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org Subject: Re: [Releasing] Qt 5.8.0 API review With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. From lars.knoll at qt.io Mon Nov 14 10:37:21 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 14 Nov 2016 09:37:21 +0000 Subject: [Releasing] [Development] Qt 5.8.0 API review Message-ID: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> Hi, I went through all modules now, and added my comments. Mainly small issues, with the exception of Qt 3D, where I see some real BC breakages. Sean, could you please look at https://codereview.qt-project.org/#/c/170642/ asap. Thanks, Lars On 14/11/16 09:44, "Jani Heikkinen" wrote: Hi all, It seems this is still badly ongoing, only few '+1' and only one '+2' there :( Please try to finalize the review during this week: We need to have reviews done & possible changes in '5.8' before we can start branching from '5.8' to '5.8.0' br, Jani ________________________________________ From: Edward Welbourne Sent: Monday, November 7, 2016 4:57 PM To: releasing at qt-project.org Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org Subject: Re: [Releasing] Qt 5.8.0 API review With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Nov 14 11:09:43 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 14 Nov 2016 10:09:43 +0000 Subject: [Releasing] Heads up - 5.8 string freeze In-Reply-To: References: Message-ID: Hi all, As warned a week ago string freeze is now in effect. Please, no changes to translatable strings from this point, unless approved by the documentation team. Br, Jani ________________________________________ From: Jani Heikkinen Sent: Monday, November 7, 2016 3:06 PM To: localization at qt-project.org Subject: Heads up - 5.8 soft string freeze Hi all, Qt 5.8 beta is out & work towards final release continues. One step on the way is String Freeze which should happen really soon to be able to minimize time needed between beta and RC. So let's have the string freeze 14th Nov 2016. Br, Jani From jani.heikkinen at qt.io Wed Nov 16 11:16:00 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 16 Nov 2016 10:16:00 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 15.11.2016 Message-ID: Meeting minutes from Qt Release Team meeting 15th November 2016 Qt 5.7.1 status: - Final packages under testing * All known blockers should be fixed * We will release these packages as Qt 5.7.1 if nothing serious found during testing Qt 5.8.0: - Header diff review ongoing * http://lists.qt-project.org/pipermail/development/2016-November/027642.html - Updated Qt 5.8.0 schedule: * Start branching Mon 21.11, final branching 28.11.2016 * RC target 13th December 2016 * Final immediately after Christmas period (3.1.2017) ** To be able to keep this we need to have all ready before Christmas break 3rd party lib updates: - From 5.6.3, 5.7.2 & 5.8.0 -> we always check the bundled 3rd parties before a release * Preferred timing: for minor/major releases before beta and for patch level release before branching Next meeting Tue 29th November 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:01:33] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:43] jaheikki3: pong [17:01:43] jaheikki3: pong [17:01:43] hello :) [17:02:43] poing [17:02:58] time to start qt release team meeting [17:03:05] on agenda today: [17:03:14] Qt 5.7.1 status [17:03:38] Qt 5.8.0 status [17:03:45] Any additional item to the agenda? [17:04:06] jaheikki3: late pong [17:05:08] update to third party [17:05:19] jaheikki3: late pong [17:05:25] I'd like to propose we always check the bundled 3rd parties before a release [17:06:18] thiago: do you mean each release of just new minor ones? [17:06:25] of==or [17:06:35] each release of ours [17:07:21] we don't want to be responsible for shipping software that contains known security issues [17:07:24] so we update [17:07:57] I generally agree, one thing is that there's a potential for breakage, so the update should happen early enough [17:08:14] and late in the process we should only take in security updates that we know about [17:08:17] for our patch releases, we should upgrade patch releases only [17:08:45] for example, the 5.7 branch (and 5.6) has libpng 1.6.20. The latest is 1.6.26. [17:08:54] yeah, agree. We need to add a step to check that. [17:10:38] Any opinions in which phase we should do that? for minor releases before beta and for patch level release before branching? [17:11:37] around branching time [17:11:54] it should land before we branch, preferably [17:12:17] I think for 5.7.1 this is too late but we could agree to do this before releasing. Or do you thiago know something why we must update some now & delay the release? [17:12:37] in addition I'd say we should encourage it at all times, not just last second [17:13:02] fregl: yes, agree. Would be good to get updates in as early as possible [17:13:42] I don't know of anything that requires urgency [17:13:58] but if something is found on things we are shipping, we'll be blamed for not shipping the latest [17:15:03] yeah, that's true. But we are that close to release with 5.7.1 and so on I wouldn't take in anything which isn't really blocking the release [17:15:06] we can begin this policy for 5.6.3 / 5.7.2 / 5.8.0 [17:15:15] +1 [17:15:51] Any objections? [17:17:17] Ok, I'll add that step in my release task list [17:17:23] sounds good [17:17:27] Then qt 5.7.1 status [17:17:43] We should have final content in place now [17:17:57] Packages are ready & undertesting [17:18:25] RTA smoke is still ongoing for LGPL packages, enterprise ones are already under manual testing [17:18:54] manual testing request will be sent to the community when RTA smoke ready [17:19:00] (if all seems to be ok) [17:19:18] what's "RTA smoke"? [17:20:15] it is simple release test automation set of test to verify all basic functionality from the packages [17:20:42] & verify that packaging went OK as well [17:21:35] ok [17:21:40] "release test automation" [17:22:29] ? [17:23:43] We are targeting to release existing packages as qt 5.7.1 if all OK according to test [17:24:25] Any comments or questions? [17:26:13] Then qt 5.8.0 status [17:26:28] string freeze in effect [17:26:57] header diff / API review ongoing. Hoping we can get it finalized during this week [17:27:44] I propose following schedule update for Qt 5.8.0: [17:28:27] - Start branching from 5.8 -> 5.8.0 Mon 21.11 & finalize it 28.11.2016 [17:28:39] header diff and API review are two different things [17:29:07] - RC target 13.12.2016 [17:29:07] they were also supposed to happen at different times [17:30:04] - Final Qt 5.8.0 release immediately after Christmas period [17:30:44] thiago: yeah. We have done API review earlier [17:31:08] thiago: And according to my understanding we are now reviewing diffs [17:31:24] or am I completely wrong? [17:37:01] we had API review near alpha and header diff is ongoing .. so jaheikki3 you are not completely wrong [17:37:14] Great :) [17:38:06] What about schedule, ok for everyone? I was planning to set 3.1.2017 to target schedule for final [17:38:21] +1 [17:38:30] +1 [17:38:53] But to reach that we need to have almost all ready before christmas [17:39:39] Great. I'll update the schedule soon in 5.8 release wiki [17:40:27] I think this was all at this time. I think we can skip next week & have new meeting Tue 29th Nov. OK? [17:40:57] ok for me [17:42:48] great. Let's end this meeting now. Bye! [17:43:00] bye [17:43:09] bye [17:43:16] byw [17:43:22] bye From lars.knoll at qt.io Fri Nov 18 15:08:28 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 18 Nov 2016 14:08:28 +0000 Subject: [Releasing] [Development] Qt 5.8.0 API review In-Reply-To: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> References: <6018DA9C-2641-4B7B-A493-BDE69C21117D@qt.io> Message-ID: <4725DCEC-80C5-4CFB-B70F-38F130CD5D33@qt.io> Hi, There are a couple of remaining issues that came up during the API review. Most of them are minor, but a couple require some attention. Never the less I decided that we can proceed and branch 5.8.0 on Monday. Because of that I would like everybody in the To line of this email to have a look at https://codereview.qt-project.org/#/c/170634/ and address the issues below as quickly as possible: Thiago, can you please have a look at the comments on qdeadlinetimer.h? Guiseppe, can you have a look at https://codereview.qt-project.org/#/c/176758/ ? Timur (and Rich), can you have a look at Jedrzej's comment in qnetworkproxy.h Laszlo, can you please comment on qeglnativecontext.h Thanks, Lars On 14/11/16 10:37, "Development on behalf of Lars Knoll" wrote: Hi, I went through all modules now, and added my comments. Mainly small issues, with the exception of Qt 3D, where I see some real BC breakages. Sean, could you please look at https://codereview.qt-project.org/#/c/170642/ asap. Thanks, Lars On 14/11/16 09:44, "Jani Heikkinen" wrote: Hi all, It seems this is still badly ongoing, only few '+1' and only one '+2' there :( Please try to finalize the review during this week: We need to have reviews done & possible changes in '5.8' before we can start branching from '5.8' to '5.8.0' br, Jani ________________________________________ From: Edward Welbourne Sent: Monday, November 7, 2016 4:57 PM To: releasing at qt-project.org Cc: Jani Heikkinen; Sune Vuorela; development at qt-project.org Subject: Re: [Releasing] Qt 5.8.0 API review With the 5.8.0 release now close at hand, I've updated the API reviews: https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 Note that, although Gerrit thinks of these as proposals to change 5.8, they are actually commits based on tag v5.7.0 showing what's changed in 5.8's API, with lots of boring bits filtered out. It would be nice if some of these did in fact get reviewed ... Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Nov 21 14:50:04 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 21 Nov 2016 13:50:04 +0000 Subject: [Releasing] HEADS-UP: Branching from '5.8' to '5.8.0' started Message-ID: Hi, We have started branching from '5.8' to '5.8.0'. Please start using '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be enough time to finalize ongoing changes in '5.8'; final downmerge will happen Monday 28th November. br, Jani From jani.heikkinen at qt.io Tue Nov 22 12:42:52 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 22 Nov 2016 11:42:52 +0000 Subject: [Releasing] Qt 5.9 In-Reply-To: References: Message-ID: Hi all, We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: - Qt 5.9.0 Feature Freeze - Changes in supported platforms/configurations So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze Then I propose following changes in supported platforms/configurations: - We have earlier agreed that for Apple we will support three latest versions. So this means * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 * For iOS we drop 7.x and support 8.x, 9.x, 10.x - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 - Start supporting QNX 7.0 br, Jani Heikkinen Release Manager From cavendish.qi at gmail.com Tue Nov 22 13:40:44 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 22 Nov 2016 13:40:44 +0100 Subject: [Releasing] [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: References: Message-ID: Then there will be batches of merges 5.6->5.7->5.8 before the final down merge 5.8->5.8.0. If your changes are after those merges, it will miss the 5.8.0 release normally. (cherry-pick only for the critical things after the final down merge.) And I plan to do the merges during weekends, if CI/COIN works fine. Or if you want your changes not missing this chance, please send some notification to me, for example, reply this email to me(not all). Best Regards, Liang On 21 November 2016 at 14:50, Jani Heikkinen wrote: > Hi, > We have started branching from '5.8' to '5.8.0'. Please start using > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > enough time to finalize ongoing changes in '5.8'; final downmerge will > happen Monday 28th November. > > br, > Jani > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Tue Nov 22 15:24:52 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 22 Nov 2016 15:24:52 +0100 Subject: [Releasing] [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: References: Message-ID: <20161122142452.GC14942@troll08> On Tue, Nov 22, 2016 at 01:40:44PM +0100, Liang Qi wrote: > Then there will be batches of merges 5.6->5.7->5.8 before the final down > merge 5.8->5.8.0. If your changes are after those merges, it will miss the > 5.8.0 release normally. > (cherry-pick only for the critical things after the final down merge.) > as this cherry-picking is kinda getting out of control, i propose the following upgrade to the branching process: - initial situation: 5.6.2 (previous lts release) is done and we want to release 5.8.0 - right after the last forward merges 5.6=>5.7=>5.8 before finishing branching 5.8.0 (that is *now*), we already create 5.6.3 - this appears obviously premature, as we just released 5.6.2, and the final downmerge from 5.6 to 5.6.3 is months away - however, this gives us a place to integrate all critical lts fixes which we can forward-merge to 5.8.0 - weird twist: after 5.8.0 gets released and 5.6.3 is forward-merged to 5.6, the branch can be temporarily closed again, until it is re-activated for the actual 5.6.3 release (or again temporarily for the 5.8.1 release) the 5.6.3 branch would be hard-branched right away and owned by RM (i.e, staging is restricted). developers need to decide between 5.6 and 5.6.3 based on whether they are targeting 5.8 or 5.8.0 when merged up. > And I plan to do the merges during weekends, if CI/COIN works fine. Or if > you want your changes not missing this chance, please send some > notification to me, for example, reply this email to me(not all). > > Best Regards, > Liang > > > On 21 November 2016 at 14:50, Jani Heikkinen wrote: > > > Hi, > > We have started branching from '5.8' to '5.8.0'. Please start using > > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > > enough time to finalize ongoing changes in '5.8'; final downmerge will > > happen Monday 28th November. > > > > br, > > Jani > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Nov 22 15:42:15 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 22 Nov 2016 14:42:15 +0000 Subject: [Releasing] [Development] HEADS-UP: Branching from '5.8' to '5.8.0' started In-Reply-To: <20161122142452.GC14942@troll08> References: <20161122142452.GC14942@troll08> Message-ID: <5E18F0E9-00C8-4A40-95BB-E0B533721224@qt.io> As long as we're still merging from 5.6 to 5.8, this is probably a good way to handle things. But since we're now having this on the table, I still believe that we need to consider when to stop doing merges from 5.6 to newer versions. This has been discussed in length at the contributor summit, and the continued merges place a rather large burden (and potential for errors) on a few people. It also tends to lead to more changes going into 5.6 than we strictly should have according to our policy. A mode where we at some point stop doing any merges from 5.6, and instead backport bug fixes into that branch will then help us distribute the 'merge' load and validation of the change in the older branch to all of us. Cheers, Lars On 22/11/16 15:24, "Development on behalf of Oswald Buddenhagen" wrote: On Tue, Nov 22, 2016 at 01:40:44PM +0100, Liang Qi wrote: > Then there will be batches of merges 5.6->5.7->5.8 before the final down > merge 5.8->5.8.0. If your changes are after those merges, it will miss the > 5.8.0 release normally. > (cherry-pick only for the critical things after the final down merge.) > as this cherry-picking is kinda getting out of control, i propose the following upgrade to the branching process: - initial situation: 5.6.2 (previous lts release) is done and we want to release 5.8.0 - right after the last forward merges 5.6=>5.7=>5.8 before finishing branching 5.8.0 (that is *now*), we already create 5.6.3 - this appears obviously premature, as we just released 5.6.2, and the final downmerge from 5.6 to 5.6.3 is months away - however, this gives us a place to integrate all critical lts fixes which we can forward-merge to 5.8.0 - weird twist: after 5.8.0 gets released and 5.6.3 is forward-merged to 5.6, the branch can be temporarily closed again, until it is re-activated for the actual 5.6.3 release (or again temporarily for the 5.8.1 release) the 5.6.3 branch would be hard-branched right away and owned by RM (i.e, staging is restricted). developers need to decide between 5.6 and 5.6.3 based on whether they are targeting 5.8 or 5.8.0 when merged up. > And I plan to do the merges during weekends, if CI/COIN works fine. Or if > you want your changes not missing this chance, please send some > notification to me, for example, reply this email to me(not all). > > Best Regards, > Liang > > > On 21 November 2016 at 14:50, Jani Heikkinen wrote: > > > Hi, > > We have started branching from '5.8' to '5.8.0'. Please start using > > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > > enough time to finalize ongoing changes in '5.8'; final downmerge will > > happen Monday 28th November. > > > > br, > > Jani > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Wed Nov 23 00:46:32 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 22 Nov 2016 23:46:32 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: References: Message-ID: > On Nov 22, 2016, at 3:42 AM, Jani Heikkinen wrote: > > Hi all, > We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) There are some things to be agreed already now: > > - Qt 5.9.0 Feature Freeze > - Changes in supported platforms/configurations > > So first of all let's agree the feature freeze date: I propose to have the FF 1.2.2017. From the history we can see that time needed from FF to final release is (even more than) 17 weeks. I know it is too long time but at the moment that is the fact and there is no evidence that we can do it within shorter schedule. We are trying to find ways to make it shorter but at the moment there isn't any big improvements coming and so on that 17 weeks is the best base for our plans. So if we want to get Qt 5.9.0 release out before summer holidays we need to have ff at the beginning of February. > > And note: At this time we want to keep the FF date to be able to keep the schedule. That means there won't be any exceptions: If feature isn't ready and in at FF date then it won't be in Qt 5.9 release. So please make sure all new features are in early enough & those are fulfilling the ff requirements: https://wiki.qt.io/Qt_5_Feature_Freeze > > Then I propose following changes in supported platforms/configurations: > > - We have earlier agreed that for Apple we will support three latest versions. So this means > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > * For iOS we drop 7.x and support 8.x, 9.x, 10.x Sounds good to me. Already got https://codereview.qt-project.org/#/c/171940/ and https://codereview.qt-project.org/#/c/171941/ ready. Also propose to "drop" tvOS 9 and watchOS 2 which were the minimums set for the technology previews introduced in 5.8. New supported versions will be tvOS 10 and watchOS 3. > - I propose to drop standalone macOS Android installer; One having iOS & Android should be enough I have a slightly different proposal: remove macOS and Android from the macOS+iOS+Android installer so that we actually *have* a standalone iOS installer. The current situation is confusing for users, and no one wants a THREE GIGABYTE installer when they possibly don't care about the other two platforms in it. > - For MinGW I propose to start delivering 64 bit binary packages instead of 32 bit one & start using MinGW 6.x (6.2?) Does this make sense when we're still delivering 32-bit MSVC packages? I'd opt to keep 32-bit or have both. > - For Windows Android I propose to start doing Android Windows build with MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8) > > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & start using term UWP (Universal Windows platform). It means also dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 Absolutely agree. > - Start supporting QNX 7.0 > > br, > > Jani Heikkinen > Release Manager > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Maurice.Kalinowski at qt.io Wed Nov 23 09:48:02 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 23 Nov 2016 08:48:02 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: References:

Message-ID: > > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 > support & start using term UWP (Universal Windows platform). It means also > dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015 > > Absolutely agree. [Kalinowski Maurice] Start using the term UWP in our website etc. WinRT is still a technical correct term for the API. So we should not start simply renaming mkspecs or such. In addition this causes a couple of changes to our CI system. My proposal would be: - Have winrt-x86-msvc2015 (or winrt-x64-msvc2015) replace the winphone-arm-msvc2013 test target on CI. Right now this would be the same build test, but I still hope that CI resources will allow regular CI auto tests at one point - Have winrt-arm-msvc2015 replace winrt-x86-msvc2015 replace to be tested during qt5.git integration. Currently Windows 10 (UWP) is only tested for the integration due to resource constraints. It should not get worse when we are removing platforms. BR, Maurice From tuukka.turunen at qt.io Thu Nov 24 06:40:12 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 24 Nov 2016 05:40:12 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: <20161123113630.GA10086@polaris.localdomain> References: <20161123113630.GA10086@polaris.localdomain> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Rafael > Roquetto > Sent: keskiviikkona 23. marraskuuta 2016 13.37 > To: Jani Heikkinen > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.9 > > Hello, > > On Tue, Nov 22, 2016 at 11:42:52AM +0000, Jani Heikkinen wrote: > > Hi all, > > > - Start supporting QNX 7.0 > > Has the QtC already laid out a plan for what needs to be considered for this? I > intend to start looking into it soon, but it would be best if we coordinated this > together in order to avoid duplicated efforts. In particular, we also want to > properly support QNX 7 on QtCreator, which is orthogonal to having QNX 7 > support on Qt 5.9, timing wise it makes sense. > To some extent, yes. Having proper c++11 support QNX 7 actually makes some things easier, while of course we still need to support QNX 6.6 as well. One of the first steps is to add QNX 7 to Qt CI system for dev and 5.9 - at least for build testing. There will be many items to tweak and polish, and hope is that you and James will participate actively, as discussed at QtCon. I am well aware the Qt release cycle is a bit quick to keep up with, but hope is we will be able to have good support for new QNX 7 already with Qt 5.9. Yours, Tuukka > Thanks, > Rafael > > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46- > 563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL > Experts From oswald.buddenhagen at qt.io Fri Nov 25 13:40:15 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 25 Nov 2016 13:40:15 +0100 Subject: [Releasing] [HEADS-UP] Updates to branching scheme Message-ID: <20161125124015.GD21393@troll08> hello, as discussed at the QtCS and these lists, forward-merging from the LTS branch 5.6 is becoming a significant burden. therefore, 5.6 is switching to a cherry-pick based model: - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to merge tags) - you may integrate only changes which have been already integrated into a stable mainline - use cherry-pick -x. don't forget to refresh the change if you create it before the source change integrates (new sha1!). - within the 5.6 "realm", there will be forward-merging from the release branch (next: 5.6.3) to 5.6 itself, so cherry-pick to only one of the 5.6.x branches. - this model is actually the same as what we employed for 4.8, our last LTS branch. - if you find that your changes recently integrated on 5.6 don't show up on 5.7 until monday, it means that you missed the last merge. in this case you'll need to _forward_-cherry-pick them. this is an exceptional case. to prevent this from happening from this point on, staging in 5.6 is temporarily locked down until we open it up again for the cherry-picks. second item: with the 5.8.0 release approaching, 5.7 is now reaching end of life. only critical fixes should go to 5.7 at this point. staging in 5.7 has been restricted to the release team, so we will be able to forward-merge 5.7 directly into 5.8.0, and we could in principle do a 5.7.2 release directly from that branch. all non-critical fixes should go to 5.8 now. i'm expecting a flurry of retargeting requests of changes from 5.6 and 5.7 to 5.8 now. regards, lars & ossi From Jake.Petroules at qt.io Mon Nov 28 19:23:02 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 28 Nov 2016 18:23:02 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: References: Message-ID: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> > On Nov 28, 2016, at 7:40 AM, Alexander Blasche wrote: > > Ok, let's summarize and restate the package list for Qt 5.9 based on the comments provided on this mail thread. The list describes the delta to Qt 5.8 packages: > > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > * For iOS we drop 7.x and support 8.x, 9.x, 10.x * For tvOS we drop 9.x and support 10.x * For watchOS we drop 2.x and support 3.x > * MinGW remains 5.3 using 32 bit > * Add MSVC 2017 64bit desktop > * Add MSVC 2017 UWP (x64, x86, armv7) > * Drop MSVC 2013 x86 > * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and WinPhone 8.1 > * Drop standalone macOS Android installer; One having iOS & Android As I said, let's not, and instead drop the massive macOS+iOS+Android installer in favor of an iOS-only installer. > * For Windows Android start doing Android Windows build with MinGW53 > * Start supporting QNX 7.0 > > -- > Alex > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From jani.heikkinen at qt.io Tue Nov 29 08:24:41 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 29 Nov 2016 07:24:41 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules > Sent: maanantaina 28. marraskuuta 2016 20.23 > To: Alexander Blasche > Cc: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Qt 5.9 > > > > On Nov 28, 2016, at 7:40 AM, Alexander Blasche > wrote: > > > > Ok, let's summarize and restate the package list for Qt 5.9 based on the > comments provided on this mail thread. The list describes the delta to Qt 5.8 > packages: > > > > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > > * For iOS we drop 7.x and support 8.x, 9.x, 10.x > > * For tvOS we drop 9.x and support 10.x > * For watchOS we drop 2.x and support 3.x > > > * MinGW remains 5.3 using 32 bit > > * Add MSVC 2017 64bit desktop > > * Add MSVC 2017 UWP (x64, x86, armv7) > > * Drop MSVC 2013 x86 > > * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and > WinPhone 8.1 > > * Drop standalone macOS Android installer; One having iOS & Android > > As I said, let's not, and instead drop the massive macOS+iOS+Android > installer in favor of an iOS-only installer. Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: - one just for macOS + another one for macOS, iOS & Android br, Jani > > > * For Windows Android start doing Android Windows build with MinGW53 > > * Start supporting QNX 7.0 > > > > -- > > Alex > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Tue Nov 29 08:32:31 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 07:32:31 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io> Message-ID: > On Nov 28, 2016, at 11:24 PM, Jani Heikkinen wrote: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >> Sent: maanantaina 28. marraskuuta 2016 20.23 >> To: Alexander Blasche >> Cc: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] Qt 5.9 >> >> >>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >> wrote: >>> >>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >> comments provided on this mail thread. The list describes the delta to Qt 5.8 >> packages: >>> >>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >> >> * For tvOS we drop 9.x and support 10.x >> * For watchOS we drop 2.x and support 3.x >> >>> * MinGW remains 5.3 using 32 bit >>> * Add MSVC 2017 64bit desktop >>> * Add MSVC 2017 UWP (x64, x86, armv7) >>> * Drop MSVC 2013 x86 >>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >> WinPhone 8.1 >>> * Drop standalone macOS Android installer; One having iOS & Android >> >> As I said, let's not, and instead drop the massive macOS+iOS+Android >> installer in favor of an iOS-only installer. > > Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? > > In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: > - one just for macOS + another one for macOS, iOS & Android I have no idea what I'm getting when I download these packages. Why do we maintain an inconsistency for macOS versus the other two host platforms? I don't see why we can't simplify this process and have ONE platform per installer... Let's focus on delivering a better experience to our users and customers instead of dropping packages just because it makes our job a little bit easier. ;) > > br, > Jani > >> >>> * For Windows Android start doing Android Windows build with MinGW53 >>> * Start supporting QNX 7.0 >>> >>> -- >>> Alex >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Jake.Petroules at qt.io Tue Nov 29 08:42:53 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 29 Nov 2016 07:42:53 +0000 Subject: [Releasing] [Development] Qt 5.9 In-Reply-To: References: <2107A1D2-A516-4248-8A98-4E636E894673@qt.io>

Message-ID: I don't know what sort of cross build and deployment environment you've set up, but I've worked with Qt Creator developing on actual embedded Linux hardware and the code-deploy-test cycle is lightning fast; no slower than desktop at all. iOS may be slower in particular due to our suboptimal build process implementation on that platform (and thus recommending that you use the iOS Simulator instead might not be a viable alternative), but I at least have never noticed any problems with slowness here so I'm not sure what you're referring to. Android, I'm not sure. Again, possibly due to the suboptimal build process implementation, but at least the emulators are blazing fast these days compared to the original SDK back in 2010 or so. > On Nov 28, 2016, at 11:37 PM, Alexander Nassian wrote: > > I don’t get the use case for having *only* iOS installed on my system. As well as for example only a cross Qt for an embedded device (iOS is practically the same thing). The normal development cycle should be (at least in my opinion) mainly develop on the desktop and check on the target in a regular manner. The cross build and deployment is enormously slower than on the desktop (which is ok with a cycle as I described), so why would I ever *only* use the cross build and deployment? Same thing for Android. Same thing for any embedded Linux target, but in contrast to Android and iOS we don’t deliver prebuilt binaries for them. > > Beste Grüße / Best regards, > Alexander Nassian > >> Am 29.11.2016 um 08:24 schrieb Jani Heikkinen : >> >>> -----Original Message----- >>> From: Development [mailto:development- >>> bounces+jani.heikkinen=qt.io at qt-project.org] On Behalf Of Jake Petroules >>> Sent: maanantaina 28. marraskuuta 2016 20.23 >>> To: Alexander Blasche >>> Cc: development at qt-project.org; releasing at qt-project.org >>> Subject: Re: [Development] Qt 5.9 >>> >>> >>>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>> wrote: >>>> >>>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >>> comments provided on this mail thread. The list describes the delta to Qt 5.8 >>> packages: >>>> >>>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>> >>> * For tvOS we drop 9.x and support 10.x >>> * For watchOS we drop 2.x and support 3.x >>> >>>> * MinGW remains 5.3 using 32 bit >>>> * Add MSVC 2017 64bit desktop >>>> * Add MSVC 2017 UWP (x64, x86, armv7) >>>> * Drop MSVC 2013 x86 >>>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>> WinPhone 8.1 >>>> * Drop standalone macOS Android installer; One having iOS & Android >>> >>> As I said, let's not, and instead drop the massive macOS+iOS+Android >>> installer in favor of an iOS-only installer. >> >> Is it really so that users of iOS installer needs only iOS binaries and nothing for desktop side? >> >> In this case I agree this might be the optimal solution but this doesn't decrease amount of our installers and that's why I prefer just dropping that one & keep those two old ones: >> - one just for macOS + another one for macOS, iOS & Android >> >> br, >> Jani >> >>> >>>> * For Windows Android start doing Android Windows build with MinGW53 >>>> * Start supporting QNX 7.0 >>>> >>>> -- >>>> Alex >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From oswald.buddenhagen at qt.io Tue Nov 29 12:41:17 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 29 Nov 2016 12:41:17 +0100 Subject: [Releasing] HEADS-UP: Branching from '5.8' to '5.8.0' complete Message-ID: <20161129114117.GB3951@troll08> On Mon, Nov 21, 2016 at 01:50:04PM +0000, Jani Heikkinen wrote: > We have started branching from '5.8' to '5.8.0'. Please start using > '5.8.0' for new changes targeted to Qt 5.8.0 release. There should be > enough time to finalize ongoing changes in '5.8'; final downmerge will > happen Monday 28th November. > with just one day of delay, this has happened now. changes on 5.8 are 5.8.1 material now. have your release-critical 5.8 changes retargeted to 5.8.0 before you integrate them. cherry-picks only in extraordinary circumstances, as usual. From jani.heikkinen at qt.io Wed Nov 30 08:31:13 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 30 Nov 2016 07:31:13 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 29.11.2016 Message-ID: Meeting minutes from Qt Release Team meeting 29th November 2016 Qt 5.7.1 status: - Unfortunately new blocker found from Device Creation testing * It seems root cause is in Qt side --> Most probably we need to update qt content once again --> No Qt 5.7.1 release during this week. New target week 49 Qt 5.8.0 status: - Branching from '5.8' to '5.8.0' finalized - Time to start creating submodule change files - Target to get RC out 13th December so there is ~ 2 weeks time to fix remaining blockers from https://bugreports.qt.io/issues/?filter=18053, get change files in & do all testing etc - Target to create first snapshot from '5.8.0' during this week Qt 5.9.0 initial schedule: - Feature Freeze & branching 1st February 2017 * Soft branching starts already 25th January 2017 - Alpha release 1st March 2017 - Beta release 5th April 2017 - RC 17th May 2017 - Final release 31st May 2017 Qt 5.6.3 schedule - Target to start creating Qt 5.6.3 release Jan/Feb 2017 & get the release out March/April 2017 Next meeting 13th December 2016 16:00 CET br, Jani irc log below: [17:00:03] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:26] jaheikki3: pong [17:00:46] pong [17:01:39] Time to start qt release team meeting [17:01:42] jaheikki3: pong [17:01:48] On agenda today: [17:01:54] qt 5.7.1 status [17:02:02] qt 5.8.0 status [17:02:11] qt 5.9 initial schedule [17:02:20] Any additional items to the agenda? [17:02:28] 5.63.? ;-) [17:03:04] fkleint: Ok, we can quickly discuss about 5.6.3 as well [17:03:07] jaheikki3: late pong [17:03:38] lets start from Qt 5.7.1 status [17:04:09] Packages has been under testing a while & we have test results available (mostly) [17:04:54] unfortunately new blocker found during device creation testing, see QTBUG-57290 [17:05:47] At the moment it seems the rootcause is in qt content and so on we need to update qt content again [17:06:07] But we will see than when the rootcause is known [17:06:20] So no qt 5.7.1 release during this week [17:06:38] otherwise packages seems to be quite ok & ready for the release [17:06:45] Any comments or questions? [17:07:53] nothing here [17:08:20] Ok, thats all about 5.7.1 at this time. Then Qt 5.8.0 status: [17:08:29] Branching finalized today [17:08:53] Time to to start creating change files for Qt 5.8.0 release (if not started yet) [17:10:34] -*- thiago hasn't had time to do header review yet [17:10:45] have we got oks on most modules already? [17:10:56] Target to get RC out 13th December so there is ~ 2 weeks time to fix remaining blockers from https://bugreports.qt.io/issues/?filter=18053, get change files in & do all testing etc [17:11:14] thiago: yes, all should be OK. lars checked those last week [17:11:50] ok [17:11:59] we have one API change to make. I'll try to do it today. [17:12:13] thiago: ok, great [17:12:59] qt5.git integration is ongoing in '5.8.0'. Hoping it succeed & we can create first snapshot for testing still during this week [17:13:09] jaheikki3: thiago: yes, I went through them all [17:13:47] That was pretty much all about 5.8.0 at this time, any more comments/questions? [17:15:43] Ok, then Qt 5.9 initial schedule [17:16:43] I proposed to have FF 1.2.2017 for Qt 5.9 in dev ml [17:17:02] sounds ok to me [17:17:20] There hasn't been any objections in ML either [17:17:42] So let's have 5.9 FF 1.2.2017 [17:18:03] That means we could have Qt 5.9 final at the end of may [17:19:10] RC mid May, Beta beginning of April and Alpha end of Feb/beginning of march [17:19:20] Any comments / questions ? [17:19:34] long time between FF and release [17:19:35] why? [17:19:55] from experience ;-) [17:19:56] oh, sorry, Feb 1 [17:20:03] damn those american dates [17:20:06] I'm getting confused [17:20:26] Yeah, FF at the beginning of Feb [17:20:37] makes sense now [17:20:54] But I agree it is quite long time from ff to final but from history we see it is best we can do atm [17:21:20] great [17:21:40] I'll update the the initial schedule in https://wiki.qt.io/Qt-5.9-release [17:21:55] Then Qt 5.6.3 schedule [17:23:33] I think there isn't any reason why we should do quick 5.6.3 release and so on I have been thinking we could start creating it ~ feb & targeting to get Qt 5.6.3 out march/april 2017 [17:23:47] Would that be OK? [17:23:55] yeah [17:24:00] sounds good [17:24:12] if we could get started in Jan would be better, but we'll see availability [17:24:34] -*- thiago will try to merge the QtDBus fixes that everyone is already deploying in January [17:25:10] Ok, great [17:25:24] I'll update 5.6.3 plan in https://wiki.qt.io/Qt-5.6-release [17:27:09] Sth from our side, we should be ready to upgrade from MSVC2015 Update 2 to MSVC2015 Update 3 (famous last words) [17:27:22] shall we wait until 5.7.1 is out and then do that? [17:28:05] fkleint: I think wait 5.7.1 at least [17:28:15] yep [17:28:19] but should we wait 5.8 as well? [17:28:29] Hm, no I think not [17:28:59] we should avoid late changes in sw as well to minimize risks [17:29:17] have we added the flag to disable the optimisation? [17:29:39] COIN now has an integration for such changes (hasn't it ;-) ? [17:29:47] in QML yes [17:30:27] https://codereview.qt-project.org/#/c/169854/ [17:30:36] I thought we were going to disable it throughout our build [17:30:40] fkleint: Have you tested the update3 with 5.8 ? if there is no real reason to update it for 5.8 I really hope we could update it for 5.9 only [17:31:05] Hm,ok, if you think so [17:31:14] Just to minimize risks [17:31:58] great [17:32:02] ok, then let's leave it at that [17:32:15] Then next meeting. We will have national holiday in finland next Tue. What is your opinion should we have a meeting wed 7.12 or just skip next week & have new one tue 13the Dec ? [17:32:26] Hi, just one point [17:32:28] Regarding the 5.9 packages (macOS/iOS/Android/... as discussed in the releasing mailing list) I also think (and always thought since mobile package appeared) that combo packages (a+b+..) are confusing, it should be one target platform per package, then up to the user to download and install more than one package as needed. [17:33:43] divide: There is many packages containing desktop + mobile targets because usually you need both. [17:34:14] But let's still continue discussion in ML to get conclusion there [17:34:22] ok [17:34:33] We aren't hurry with that decision yet ;) [17:34:54] sure :) but since it always bothered me, I'm taking the chance... :) [17:34:57] -*- thiago would prefer Dec 13 meeting [17:35:24] divide: Yeah, that's OK & wellcome ;) [17:35:31] Dec 7 I can't join [17:35:57] ok, let's skip next week & have new meeting dec 13 at this same time [17:36:52] It was all at this time. Thanks for your participation. Bye! [17:37:07] bye