<div dir="ltr">Hi,<div class="gmail_extra">
<br><div class="gmail_quote">On Tue, Oct 20, 2015 at 10:52 PM, Mathieu Pellerin <span dir="ltr"><<a href="mailto:nirvn.asia@gmail.com" target="_blank">nirvn.asia@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Nyall,<br><br></div>Great initiative! The sooner a plan can be agreed upon, the better.<br><br>Coincidentally
to your QEP proposal, I came up with an alternative timeline idea over
the last few days that would avoid skipping a release cycle but still
give us enough time to complete the port to Qt5.<br><br>Basically, we
begin the development cycle of both 2.14 LTR _as well as_ 3.0 at the
same time, following the public release of 2.12. The simultaneous
overlapping development of those two versions (for the first four
months) would have two distinct objectives and release dates:<br>- for
2.14 LTR, the development cycle would last 4 months and would be
released, as planned, on 26.02.2016 with a focus on stability and bugfix
based on the feedback from users on 2.12 (small-ish new features could
be pushed too)<br>- for 3.0, the development cycle would last 8 months,
with the first four months overlapping with the development of 2.14 LTR,
and be released on 26.06.2016 (as our 4-month release cycle would have
it following the release of 2.14 LTR) with a focus on porting QGIS to
Qt5 and python 3 as well as significant new features.<br><br>This
alternate timeline proposal both speeds up the delivery of QGIS 3.0 as
well as insuring QGIS 2.14 LTR is shipped with a focus on stability as
devs can push new features onto QGIS 3.0.<br><br>Thoughts?</div></blockquote><div><br></div><div>I like the idea of 8 months of work for a 3.0 release, with 4 months concurrent with the 2.14 dev cycle. Although, I think the last thing we need during the 3.0 porting process is to be bogged down with new bugs and regressions introduced by 'significant new features.'</div><div><br></div><div>If 3.0 is the first to introduce Qt5/Py3, and we have 8 months of work, I think the initial focus should be merely to do porting, and do it well, rather than fragment development with yet more features and end up with a half-baked Qt5/Py3 porting. However, with 8 months of work, it may be reasonable to reassess the situation after 4 months of porting effort.</div><div><br></div><div>In other words, an approach might be that for the first 4 months ONLY porting and bug fixing can be done to the 3.0 branch, with no new features. Then, alongside the 2.14 LTR, we could do a 3.0 beta release for third-party plugin devs and interested power users, educators and sys admins to work with. After which, we can open up the 3.0 branch for new feature development. </div><div><br></div><div>Such an approach would have the following effects:</div><div><br></div><div>* Developers would be hesitant to add significant new features to the 2.14 if they could not readily port the feature to 3.0. (This keeps everyone focused on porting efforts for 3.0, and avoids regressions for 2.14.)</div><div><br></div><div>* The 2.14 LTR dev cycle will have limited feature development, allowing for increased focus on stability bug fixes. This is critical if the 2.14 LTR might be a version many users stick with due to plugin compatibility issues. We don't want the last 2.x release to have new bugs/regressions if many devs will be dropping work on it to focus on 3.0. <br></div><div><br></div><div>* After the 2.14 LTR is released, new features go into 3.0, and minimal backporting of fixes would be required for the LTR, because 2.14 development should not have significantly increased bugs and regressions with its limited new feature development.</div><div><br></div><div>Regards,</div><div><br></div><div>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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 10:30 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
Thought I'd try and get things moving on this. Please see<br>
<br>
<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/pull/24" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/pull/24</a><br>
<br>
for a QEP regarding QGIS 3.0 being the release after 2.14 and the<br>
changes proposed for 3.0.<br>
<br>
Feedback welcome!<br>
Nyall<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">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><br></div>
</div></div><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></blockquote></div><br></div></div>