<div dir="ltr">Hi,<div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Oct 21, 2015 at 3:47 PM, 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"><span class="">On 22 October 2015 at 01:44, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com">larrys@dakotacarto.com</a>> wrote:<br>
<br>
><br>
><br>
> I like the idea of 8 months of work for a 3.0 release, with 4 months<br>
> concurrent with the 2.14 dev cycle. Although, I think the last thing we need<br>
> during the 3.0 porting process is to be bogged down with new bugs and<br>
> regressions introduced by 'significant new features.'<br>
<br>
</span>MMm... I disagree here. Some features REQUIRE an API break, so this<br>
would be our only chance to do this within the next ~3-4 years. I<br>
don't think we should restrict this.</blockquote><div><br></div><div>I meant specifically during the porting process. Then, break the API and add new features. For example, some plugin devs might need to fix up their plugins for all three: Qt5, Py3 and API. If we do all three and introduce new features, during the porting process, it might be total chaos for them.</div><div><br></div><div>If during the 8-month 3.0 dev cycle we:</div><div>* port to Qt5/Py3 (however long that takes), then release a public beta</div><div>* continue with removing deprecated items, API break and new features</div><div><br></div><div>this will allow plugin devs to use the beta to port their plugins to Qt5/Py3, without worrying about missing deprecated APIs and new API changes at the same time. They can use nightlies from then on to keep up with any API changes and port their plugins accordingly. Might be good after the beta release to have periodic public announcements about what in the API has changed.</div><div><br></div><div>This would isolate the later API changes/breaks, which could be very difficult to fix for some plugins, from the more straightforward task of porting to Qt5/Py3.</div><div><br></div><div>Is this a reasonable approach, or is it not worth trying to maintain the current API while porting to Qt5?</div><div><br></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"><span class=""><br>
><br>
> If 3.0 is the first to introduce Qt5/Py3, and we have 8 months of work, I<br>
> think the initial focus should be merely to do porting, and do it well,<br>
> rather than fragment development with yet more features and end up with a<br>
> half-baked Qt5/Py3 porting.<br>
<br>
</span>Fair enough, I'll concede that point.<br>
<br>
<br>
Why not:<br>
<br>
- branch off master after 2.12 to 2.14. 2.14 becomes an LTR candidate<br>
- ONLY bug fixes allowed to be pushed to that branch, no new features.<br>
This means 2.14 will effectively have a whole release cycle of bug<br>
fixes only, hopefully resulting in the "best most stablest QGIS<br>
release EVA!" (or something). This would benefit all the users who<br>
will be forced to stay on 2.14 for the foreseeable future due to<br>
plugins/other reasons they can't move to 3.0.<br></blockquote><div><br></div><div>Only allowing bug fixes starting next week, without any notification of such a change in plan to the public, might be bad form. There may be features that, while not new, might need more work. An example I am familiar with: it would be good to integrate the new auth system with more connections.</div><div><br></div><div>Such 'features' might need some type of moderator. Could have all 'possibly a new feature' commits to the 2.14 LTR be required via PR?</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">
- development continues on master for what will become 3.0. Initial<br>
focus is on removing deprecated methods and classes and porting to Qt5<br>
& python 3.0 quickly. Possibly QGIS organisation could sponsor a dev<br>
to look into this (*cough* Matthias *cough*) so that we can make the<br>
transition rapidly and then plugin devs have the largest time<br>
available to port before release. (Of course, API will still change<br>
throughout the 2.999/pre 3.0 development cycle, so it must be<br>
understood that porting will be a ongoing process while the API is<br>
fluid). After we switch to Qt5/Python 3.0, development opens up to new<br>
features.<br>
<br>
- QGIS 3.0 is released instead of 2.16, 8 months from now.<br>
<span class=""><font color="#888888"><br>
Nyall<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
> However, with 8 months of work, it may be<br>
> reasonable to reassess the situation after 4 months of porting effort.<br>
><br>
> In other words, an approach might be that for the first 4 months ONLY<br>
> porting and bug fixing can be done to the 3.0 branch, with no new features.<br>
> Then, alongside the 2.14 LTR, we could do a 3.0 beta release for third-party<br>
> plugin devs and interested power users, educators and sys admins to work<br>
> with. After which, we can open up the 3.0 branch for new feature<br>
> development.<br>
><br>
> Such an approach would have the following effects:<br>
><br>
> * Developers would be hesitant to add significant new features to the 2.14<br>
> if they could not readily port the feature to 3.0. (This keeps everyone<br>
> focused on porting efforts for 3.0, and avoids regressions for 2.14.)<br>
><br>
> * The 2.14 LTR dev cycle will have limited feature development, allowing for<br>
> increased focus on stability bug fixes. This is critical if the 2.14 LTR<br>
> might be a version many users stick with due to plugin compatibility issues.<br>
> We don't want the last 2.x release to have new bugs/regressions if many devs<br>
> will be dropping work on it to focus on 3.0.<br>
><br>
> * After the 2.14 LTR is released, new features go into 3.0, and minimal<br>
> backporting of fixes would be required for the LTR, because 2.14 development<br>
> should not have significantly increased bugs and regressions with its<br>
> limited new feature development.<br>
><br>
> Regards,<br>
><br>
> Larry Shaffer<br>
> Dakota Cartography<br>
> Black Hills, South Dakota<br>
><br>
>><br>
>> On Wed, Oct 21, 2015 at 10:30 AM, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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">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>
>><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>
><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>
</div></div></blockquote></div><br></div></div>