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

[Nyall Dawson]

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.

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

- 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