<div dir="ltr">Hi,<div><br></div><div>I agree with Nyall. As this is a major release this requires more time, have a look at how long it took Python 3 to finally become used for an idea on how people treat major breaks in API.</div><div><br></div><div>As we already have 2.14, 1.6 and 2.18 out the door as a really good base I don't see a need to rush this out.</div><div><br></div><div>I have plans for 3.0 but don't have a Windows build setup yet.</div><div><br></div><div>Regards,<br>Nathan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 4:10 PM, Neumann, Andreas <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Hi,</p>
<p>It would be fine for me to have a double dev cycle for 3.0. Devs should have enough time to make proper decisions and work on the API. And python devs probably also need more time to get their most important plugins in shape for the new API, qt5 and Python 3.</p>
<p>Perhaps it would be good to also have more than one month for testing and bug fixing - extending this to two months. We could simply shift the one month bug fixing/testing of the first cycle towards the end of the second cycle.</p>
<p>So this modified proposal would mean:</p>
<p>Feature freeze at the end of May, release at the end of July. Right?</p>
<p>Fine with me, if we still care about the 2.x branch where necessary - preferably investing more in 2.18x than in 2.14x (my personal opinion).</p><span class="HOEnZb"><font color="#888888">
<p>Andreas</p></font></span><div><div class="h5">
<p>On 2016-10-26 07:53, Nyall Dawson wrote:</p>
<blockquote type="cite" style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">
<div class="m_5056616331373819536pre" style="margin:0;padding:0;font-family:monospace">Hi all,<br><br> I'd like to start the discussion around this early so that we can plan<br> ahead and not have to make a last-minute decision.<br><br> What are everyone's thoughts on extending the timeline for 3.0? In my<br> opinion things are currently going really well, we have Qt5/python3<br> builds which are stable enough for daily use and there's been a ton of<br> cleanups to the code.<br><br> There's a lot of changes still coming in, and I think there's SO much<br> room for making things better that I don't like the idea of the early<br> 2017 deadline for the final release. I'd much rather extend this out<br> by another cycle and really getting the platform ready for the next<br> series of QGIS releases.<br><br> We could always put out a "preview" release in March, without frozen<br> API, if desired.<br><br> So, what's everyone's thoughts? Good idea? Bad idea?<br><br> Nyall<br> ______________________________<wbr>_________________<br> Qgis-developer mailing list<br><a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div>
</blockquote>
<p> </p>
<div> </div>
</div></div></div>
<br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br></blockquote></div><br></div>