On 25 October 2015 at 22:03, Matthias Kuhn <matth...@opengis.ch> wrote: > > On 10/25/2015 08:23 AM, Nathan Woodrow wrote: >> >> Of course we can develop it without breaking anything if done in a >> branch. But having a plan around all this is the point of all this I >> think just so we are all on the same page >> >> > > We do (most likely) not need to keep it in a separate branch. Just like > we do not have a Qt5 branch. It's all in master. > > My point is: > > If we think about taking the step towards QGIS 3 with py3 and pyqt5 > anytime soon, then the first steps are clear anyway. And probably not > even too hard. > > Having a plan is good. Having a plan based on solid knowledge is better. >
I'd like to get this discussion moving again, since timing is critical. What I see as the way forward: - Get PSC to vote on and accept https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29 . Needs to be done ASAP so that we're all agreed that 2.14 is the last 2.0 series release. - Decide on the timing for 3.0. Specifically, will the normal scheduled release after 2.14 be skipped to allow for a longer development cycle for 3.0. Regarding this, my opinion is that we NEED the longer cycle to allow room for the (non Qt5/python 3.0) related changes which we can ONLY make for an API breaking release. There's already a long list at https://github.com/qgis/qgis3.0_api/issues, and I suspect this is only scratching the surface. Without sufficient time for devs to address these API related issues we'll be stuck with the limitations of the current API for another 2-3 years. Anyway, can we please lock in point 1 above so that we can move the discussion on to timing? Nyall _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
