<div dir="ltr">Hi,<div class="gmail_extra">
<br><div class="gmail_quote">On Thu, Oct 22, 2015 at 2:53 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"><div class=""><div class="h5">On 22 October 2015 at 19:52, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br>
> On 22 October 2015 at 12:28, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com">larrys@dakotacarto.com</a>> wrote:<br>
>><br>
>> I meant specifically during the porting process. Then, break the API and add<br>
>> new features. For example, some plugin devs might need to fix up their<br>
>> plugins for all three: Qt5, Py3 and API. If we do all three and introduce<br>
>> new features, during the porting process, it might be total chaos for them.<br>
>><br>
>> If during the 8-month 3.0 dev cycle we:<br>
>> * port to Qt5/Py3 (however long that takes), then release a public beta<br>
>> * continue with removing deprecated items, API break and new features<br>
>><br>
>> this will allow plugin devs to use the beta to port their plugins to<br>
>> Qt5/Py3, without worrying about missing deprecated APIs and new API changes<br>
>> at the same time. They can use nightlies from then on to keep up with any<br>
>> API changes and port their plugins accordingly. Might be good after the beta<br>
>> release to have periodic public announcements about what in the API has<br>
>> changed.<br>
>><br>
>> This would isolate the later API changes/breaks, which could be very<br>
>> difficult to fix for some plugins, from the more straightforward task of<br>
>> porting to Qt5/Py3.<br>
>><br>
>> Is this a reasonable approach, or is it not worth trying to maintain the<br>
>> current API while porting to Qt5?<br>
><br>
> I like it. We'll probably need to be a bit flexible with your last<br>
> note and not worry too much about strictly maintaining the api during<br>
> the Qt5 port (given that it'll break anyway, it seems a bit silly to<br>
> have to code workarounds to temporarly maintain API). But generally,<br>
> I'm in favour.<br>
><br>
> Do you (or someone else?) mind submitting a similar QEP with this<br>
> proposed schedule. and then we can send both alternative approaches to<br>
> the PSC to decide between?<br>
<br>
</div></div>Also should have said that the sooner we get this locked in the<br>
better... if master is about to unfreeze it'd be better if the<br>
approach for 2.14 was already decided on.<br></blockquote><div><br></div><div>Hmm. You mean put in a QEP tomorrow, and ask the PSC to vote on that early next week? I would think at least a week of dev community comments on such a QEP would be warranted, given the very large scope.</div><div><br></div><div>Maybe ask Jürgen and PSC for one extra week of feature freeze on master branch while this is decided?</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">
<span class=""><font color="#888888"><br>
Nyall<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
><br>
> Nyall<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>><br>
>>><br>
>>> ><br>
>>> > If 3.0 is the first to introduce Qt5/Py3, and we have 8 months of work,<br>
>>> > 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<br>
>>> > a<br>
>>> > half-baked Qt5/Py3 porting.<br>
>>><br>
>>> 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>
>><br>
>><br>
>> Only allowing bug fixes starting next week, without any notification of such<br>
>> a change in plan to the public, might be bad form. There may be features<br>
>> that, while not new, might need more work. An example I am familiar with: it<br>
>> would be good to integrate the new auth system with more connections.<br>
>><br>
>> Such 'features' might need some type of moderator. Could have all 'possibly<br>
>> a new feature' commits to the 2.14 LTR be required via PR?<br>
>><br>
>>><br>
>>> - 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>
>>><br>
>>> Nyall<br>
>>><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<br>
>>> > features.<br>
>>> > Then, alongside the 2.14 LTR, we could do a 3.0 beta release for<br>
>>> > 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<br>
>>> > 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<br>
>>> > 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<br>
>>> > issues.<br>
>>> > We don't want the last 2.x release to have new bugs/regressions if many<br>
>>> > 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<br>
>>> > 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>
>><br>
>><br>
</div></div></blockquote></div><br></div></div>