On 22 October 2015 at 12:28, Larry Shaffer <lar...@dakotacarto.com> wrote: > > 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. > > If during the 8-month 3.0 dev cycle we: > * port to Qt5/Py3 (however long that takes), then release a public beta > * continue with removing deprecated items, API break and new features > > 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. > > 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. > > Is this a reasonable approach, or is it not worth trying to maintain the > current API while porting to Qt5?
I like it. We'll probably need to be a bit flexible with your last note and not worry too much about strictly maintaining the api during the Qt5 port (given that it'll break anyway, it seems a bit silly to have to code workarounds to temporarly maintain API). But generally, I'm in favour. Do you (or someone else?) mind submitting a similar QEP with this proposed schedule. and then we can send both alternative approaches to the PSC to decide between? Nyall > >> >> > >> > 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. >> >> Fair enough, I'll concede that point. >> >> >> Why not: >> >> - branch off master after 2.12 to 2.14. 2.14 becomes an LTR candidate >> - ONLY bug fixes allowed to be pushed to that branch, no new features. >> This means 2.14 will effectively have a whole release cycle of bug >> fixes only, hopefully resulting in the "best most stablest QGIS >> release EVA!" (or something). This would benefit all the users who >> will be forced to stay on 2.14 for the foreseeable future due to >> plugins/other reasons they can't move to 3.0. > > > 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. > > 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? > >> >> - development continues on master for what will become 3.0. Initial >> focus is on removing deprecated methods and classes and porting to Qt5 >> & python 3.0 quickly. Possibly QGIS organisation could sponsor a dev >> to look into this (*cough* Matthias *cough*) so that we can make the >> transition rapidly and then plugin devs have the largest time >> available to port before release. (Of course, API will still change >> throughout the 2.999/pre 3.0 development cycle, so it must be >> understood that porting will be a ongoing process while the API is >> fluid). After we switch to Qt5/Python 3.0, development opens up to new >> features. >> >> - QGIS 3.0 is released instead of 2.16, 8 months from now. >> >> Nyall >> >> >> >> >> >> >> > However, with 8 months of work, it may be >> > reasonable to reassess the situation after 4 months of porting effort. >> > >> > 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. >> > >> > Such an approach would have the following effects: >> > >> > * 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.) >> > >> > * 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. >> > >> > * 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. >> > >> > Regards, >> > >> > Larry Shaffer >> > Dakota Cartography >> > Black Hills, South Dakota >> > >> >> >> >> On Wed, Oct 21, 2015 at 10:30 AM, Nyall Dawson <nyall.daw...@gmail.com> >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> Thought I'd try and get things moving on this. Please see >> >>> >> >>> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/24 >> >>> >> >>> for a QEP regarding QGIS 3.0 being the release after 2.14 and the >> >>> changes proposed for 3.0. >> >>> >> >>> Feedback welcome! >> >>> Nyall >> >>> _______________________________________________ >> >>> Qgis-developer mailing list >> >>> Qgis-developer@lists.osgeo.org >> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> >> >> >> >> >> _______________________________________________ >> >> Qgis-developer mailing list >> >> Qgis-developer@lists.osgeo.org >> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > >> > >> > >> > _______________________________________________ >> > Qgis-developer mailing list >> > Qgis-developer@lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
