<div dir="ltr">+1 <div><br></div><div>Tim can I get a vote for QEP 29 setup on the platform we are using please. (<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29</a>)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 7:04 AM, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 25 October 2015 at 22:03, Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> wrote:<br>
><br>
> On 10/25/2015 08:23 AM, Nathan Woodrow wrote:<br>
>><br>
>> Of course we can develop it without breaking anything if done in a<br>
>> branch.  But having a plan around all this is the point of all this I<br>
>> think just so we are all on the same page<br>
>><br>
>><br>
><br>
> We do (most likely) not need to keep it in a separate branch. Just like<br>
> we do not have a Qt5 branch. It's all in master.<br>
><br>
> My point is:<br>
><br>
> If we think about taking the step towards QGIS 3 with py3 and pyqt5<br>
> anytime soon, then the first steps are clear anyway. And probably not<br>
> even too hard.<br>
><br>
> Having a plan is good. Having a plan based on solid knowledge is better.<br>
><br>
<br>
<br>
</div></div>I'd like to get this discussion moving again, since timing is critical.<br>
<br>
What I see as the way forward:<br>
<br>
- Get PSC to vote on and accept<br>
<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29</a> . Needs<br>
to be done ASAP so that we're all agreed that 2.14 is the last 2.0<br>
series release.<br>
<br>
- Decide on the timing for 3.0. Specifically, will the normal<br>
scheduled release after 2.14 be skipped to allow for a longer<br>
development cycle for 3.0. Regarding this, my opinion is that we NEED<br>
the longer cycle to allow room for the (non Qt5/python 3.0) related<br>
changes which we can ONLY make for an API breaking release. There's<br>
already a long list at <a href="https://github.com/qgis/qgis3.0_api/issues" rel="noreferrer" target="_blank">https://github.com/qgis/qgis3.0_api/issues</a>, and<br>
I suspect this is only scratching the surface. Without sufficient time<br>
for devs to address these API related issues we'll be stuck with the<br>
limitations of the current API for another 2-3 years.<br>
<br>
Anyway, can we please lock in point 1 above so that we can move the<br>
discussion on to timing?<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span></blockquote></div><br></div>