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

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>