<p dir="ltr">As Jürgen said, it's essentially the same. Yet... :)</p>
<p dir="ltr">I also think branching off 2.14 LTR now is slightly preferable. On a psychological level, as the heavy development of new features has in the past mostly taken place on the master branch, it'd make it clearer to devs that the heavy feature development takes place there, and not on the 2.14 LTR branch.</p>
<p dir="ltr">Alternatively, we could branch off 2.14 LTR very early on,  like in a month's time. That would give a preparatory period for new packages for osgeo4w etc.</p>
<div class="gmail_quote">On 24 Oct 2015 06:24, "Nyall Dawson" <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 24 October 2015 at 07:26, Jürgen E. <<a href="mailto:jef@norbit.de">jef@norbit.de</a>> wrote:<br>
> Hi,<br>
><br>
> On Thu, 22. Oct 2015 at 08:47:26 +1100, Nyall Dawson wrote:<br>
>> Why not:<br>
><br>
> - Branch off a qt5 branch from master now and start with porting<br>
> - continue as usual with master to produce 2.14<br>
> - branch 2.14 off and release it in four month<br>
> - then merge the qt5 branch into master (aka 2.15)<br>
> - finally branch 3.0 off and release it in eight month<br>
><br>
> Essentially the same - but with the benefit for me that the nightlies and<br>
> packaging scripts can continue as is - and there are four more month to get the<br>
> dependencies in place (ie. Qt5, PyQt5, Python3 in OSGeo4W).<br>
<br>
<br>
Sorry Jürgen, when I was thinking more about this I realised I also<br>
should have also included you in the potential list of devs who<br>
could/should be funded by QGIS org to complete this work. I realise<br>
that this is a considerable task to get all the dependencies ready<br>
too! Apologies for that, and no slight was intended by not mentioning<br>
this earlier.<br>
<br>
My concern with this approach would be that we'd need to make sure<br>
it's known that major changes aren't acceptable for 2.14. If 2.14 was<br>
branched off from master early then this would be immediately evident,<br>
but if not then we need to make it well known to devs that the usual<br>
rules don't apply during the 2.14 cycle...<br>
<br>
Also in the ideal world we'd have the Qt5/python 3 test builds<br>
available asap so that people can start testing/porting plugins. But<br>
understandably this isn't an easy task.<br>
<br>
Otherwise, I'd also be happy with this approach.<br>
<br>
Nyall<br>
<br>
<br>
<br>
<br>
<br>
><br>
><br>
> Jürgen<br>
><br>
> --<br>
> Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31<br>
> Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50<br>
> Software Engineer           D-26506 Norden             <a href="http://www.norbit.de" rel="noreferrer" target="_blank">http://www.norbit.de</a><br>
> QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode<br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>