[Qgis-developer] QEP - Proposal for QGIS 3.0 after 2.14

Larry Shaffer larrys at dakotacarto.com
Thu Oct 22 09:01:26 PDT 2015


Hi,

On Thu, Oct 22, 2015 at 2:53 AM, Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> On 22 October 2015 at 19:52, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> > On 22 October 2015 at 12:28, Larry Shaffer <larrys at 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?
>
> Also should have said that the sooner we get this locked in the
> better... if master is about to unfreeze it'd be better if the
> approach for 2.14 was already decided on.
>

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.

Maybe ask J├╝rgen and PSC for one extra week of feature freeze on master
branch while this is decided?

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota


>
> Nyall
>
>
>
>
> >
> > 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.dawson at 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 at lists.osgeo.org
> >>> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>> >>
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> Qgis-developer mailing list
> >>> >> Qgis-developer at lists.osgeo.org
> >>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>> >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Qgis-developer mailing list
> >>> > Qgis-developer at lists.osgeo.org
> >>> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151022/1d602489/attachment-0001.html>


More information about the Qgis-developer mailing list