> On Nov 29, 2016, at 11:28 PM, Alexander Blasche <alexander.blas...@qt.io> > wrote: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Jake Petroules > >>> That's why I still think we should proceed as I proposed: Keep online >>> offering >> as it is but drop separate macos + android offline installer (have macOS and >> macOS + mobile targets for macOS offline offering). Decreasing our offline >> installer offering is essential; needed testing effort at the moment is >> really huge >> & it is increasing all the time because of these parallel releases. That's >> why we >> need to decrease stuff to be tested to make our live easier. >> >> So don't test them. I'm not joking. There should be no reason to test every >> possible combination; just test each platform through the online installer >> and >> that should implicitly test that the offline one works. > > Sorry but that's not going to fly. > >> Our process shouldn't be so flimsy and untrustworthy that we're testing every >> possible combination. Let the community do it, and if there's a problem, >> we'll >> surely know soon enough. > > Software is a living and breathing thing. Its nature is such that it evolves > changes each time. Not testing is not an option. We could have more > confidence if history wouldn't proof us constantly wrong. Jake, even you had > your fair share of breaks during release time. Stop breaking other platforms > with your iOS changes and we can talk again ;) > > You can use the online installer if you want only one mobile platform but not > the other. Sure there is more MBs to download with offline but the releasing > and testing effort is an even greater concern. > > Dropping 32bit once Apple says so is a much more rewarding and likely > opportunity.
How about we have one package per host platform which includes all possible hosts and targets compatible with it? Then we have 3 packages, ever. If our releasing and testing effort is the #1 concern over anything else, then having multi-gigabyte packages should not be a problem. We can then have: Windows host: includes Windows (i386-2015,x86_64-2015,i386-2015-winrt,x86_64-2015-winrt,armv7-2015-winrt) + Android (armv7,x86) macOS host: includes macOS (x86_64) + iOS (armv7,arm64,i386,x86_64) + Android (armv7,x86) Linux host: includes Linux (x86_64) + Android (armv7,x86) + QNX (armv7,x86)? By this estimation the Windows one would be around 3.5 GB (maybe less), about the same as the combined macOS+iOS+Android installer. In fact, because the WinRT and desktop binaries should be identical or very similar in many cases, they might compress even better than that (and/or we can look into the possibility of creating a unified Windows build whose DLLs work in either a classic desktop OR WinRT environment, and switch on the platform plugin. not sure to what degree that's possible) We could add the two 2013 builds (2013 WinRT is dead, so 2, not 4 or 5) and the MinGW to the Windows installer, ballooning it to around 6 GB or so (again, this may be totally fine), or we could separate those into 1 or 2 extra installers. Then we have between 3 and 5 rather than 13 like the 5.8 beta has currently. I don't know how useful the offline installers really are, so having the few users suffer a bit over longer download times should be OK given the nice tradeoff in testing. 90% of users should be on the online installer anyways. So, any good reasons we shouldn't do this? > >> One solution could be that we start using online ones at first & bring >> offline ones >> later. Earlier we have released beta with offline only so should we do this >> differently with Qt 5.9: >>> >>> Qt 5.9 alpha: src only >>> Qt 5.9 beta: online only > > I am against this. Online installers are much harder to handle when you have > to continuously install competing Qt versions. Testing requires to install 4 > different builds of Qt during for example beta time. Both types of builds > have their advantage and testing/trialing is not one where the online > installer shines. > > -- > Alex -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
