<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature">Hi,</div></div>
<br><div class="gmail_quote">On Wed, May 4, 2016 at 10:09 AM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On 04/05/16 16:49, Bas Couwenberg wrote:<br>
> On 2016-05-04 15:08, Matthias Kuhn wrote:<br>
>>> For the upstream QGIS packages this may be an option, for the official<br>
>>> packages in the Debian archive it is not.<br>
>><br>
>> Understandable.<br>
>><br>
>> I had a look at past Debian releases, extrapolating the release cycle we<br>
>> can expect the next release to happen in about a year.<br>
>><br>
>> I don't expect a first QGIS release based on Qt5 to happen considerably<br>
>> earlier. The first LTR based on Qt5 will certainly not happen earlier.<br>
>><br>
>> Just to make sure we talk about the same order of delays. (Note: this<br>
>> timeline has not been officially approved)<br>
><br>
> Debian will switch to Qt5 with QGIS 2.16, otherwise there will be no<br>
> QGIS in the next stable release.<br>
<br>
</span>I don't want to prevent you from doing that, the worst that could happen<br>
is that you will need to set a CMake flag to void the non-existent<br>
warranty. QGIS will happily compile and run with any Qt5 version (for now).<br>
<br>
Just be prepared that:<br>
<br>
 * Almost every plugin will fail (most of them with import PyQt and<br>
python 3 related errors)<br>
 * Even if they are migrated anything related to NULL values will still<br>
fail because of the issue under discussion<br>
 * This will be the case regardless of the approach to overcome this<br>
problem (Qt 5.7 or sip.enableautoconversion(false))<br>
<span class=""><br>
> The Qt4 builds currently still work because the Qt maintainers didn't<br>
> want to break QGIS before Qt5 support is available, but the Qt4WebKit<br>
> removal changes have already been committed and will be included in<br>
> the next upload. The upload may happen sooner than we'd like if<br>
> important bugfixes need to be uploaded in the near future.<br>
<br>
</span>I'm happy to have Debian users as guinea pigs - but if you want to give<br>
the best UX instead of the latest bleeding edge code with known<br>
problems, you probably better continue shipping the current Qt4 builds<br>
wherever possible.<br>
<br>
I can try to see if there's another solution which only requires a sip<br>
update and not a Qt5 update which could possibly increase the number of<br>
possible target platforms.<br>
<span class=""><br>
On 04/05/16 17:36, Larry Shaffer wrote:<br>
> I have started in on a complete rewrite of the CMake bundling for Mac<br>
> (leveraging BundleUtilities) that can utilize a Homebrew backend of<br>
> dependencies and generate a completely bundled app directly from a<br>
> Homebrew formula. When would be a good timeframe to start releasing a<br>
> Mac Qt5/Py3 nightly?<br>
><br>
> Also, what would be the best nightly configurations for Mac to offer?<br>
> Qt4/Py2, of course, but what other combinations make sense, i.e.<br>
> Qt?/Py?, for testing? Or, should we focus only on offering two:<br>
> Qt4/Py2, Qt5/Py3?<br>
<br>
</span>That is great news Larry.<br>
<br>
I would stick to Qt5/Py3 (and Qt4/Py2) to keep the matrix small and<br>
avoid plugins developed against strange combinations. In the case of OSX<br>
a combination of Qt5/PyQt4/Py2 may also make sense because I think there<br>
are Qt4 compatibility issues with OSX which this combination may<br>
overcome while still offering support for the current plugin ecosystem.<br>
But that's just a guess.<br></blockquote><div><br></div><div>Yes, that Qt5/PyQt4/Py2 make sense during the migration period (6 to 12 months?). </div><div><br></div><div>I think having Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for Mac is not unreasonable. This will help plugin authors and core testers migrate code, since all three could be installed on a dev Mac at the same time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
What I am really interested in is a Qt5/Python3 OSX build on travis. The<br>
sooner we can have this the better. It could even have an on_success or<br>
deploy step to upload master builds from the test infrastructure.<br></blockquote><div><br></div><div>That sounds great, if we can find a way to do that on a nightly basis. Seems a bit excessive to do per Travis test build, i.e. per every commit and PR. Well, at least for full bundling, which takes a while and might clog the Travis queue.</div><div><br></div><div>Another option is to do a minimum bundled build (just qgis libs/frameworks, Python modules and plugins). Then a user would need to have a Homebrew dependency install to work with the artifacts. That might be the simplest. It would be equivalent to the QGIS.app inside of the Homebrew qgis-214 prefix install, or ~58 MB compressed. Note, I do something similar at work already, though via Jenkins builds. Would make it VERY easy/fast to functionally test PRs on Mac.</div><div><br></div><div>It will require the minimum Mac OS to be 10.9 (Travis-supported OS) instead of the current 10.7, but I was going to bump the nightlies to 10.9 anyhow, since anything less than that is not supported via 'bottles' upstream by Homebrew. Also, it's a totally reasonable minimum OS for a nightly.</div><div><br></div><div>This seems like a good plan to me:</div><div>* New Homebrew-based Mac bundling CMake routines have two bundling outputs: minimal and full<br></div><div>* Travis Mac build produces a minimally bundled app as an output artifact, which requires a Homebrew install of deps to use</div><div>* Generate fully bundled Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for local isolated testing of plugins and core</div><div><br>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Regards<br>
<span class=""><font color="#888888">Matthias<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div></div></blockquote></div><br></div></div>