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

Wed Oct 21 18:28:55 PDT 2015

Hi,

On Wed, Oct 21, 2015 at 3:47 PM, Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> On 22 October 2015 at 01:44, Larry Shaffer <larrys at dakotacarto.com> wrote:
>
> >
> >
> > I like the idea of 8 months of work for a 3.0 release, with 4 months
> > concurrent with the 2.14 dev cycle. Although, I think the last thing we
> need
> > during the 3.0 porting process is to be bogged down with new bugs and
> > regressions introduced by 'significant new features.'
>
> MMm... I disagree here. Some features REQUIRE an API break, so this
> would be our only chance to do this within the next ~3-4 years. I
> don't think we should restrict this.

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?

> >
> > 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/20151021/47651815/attachment-0001.html>