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

[Nyall Dawson]

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?

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
>
>