[Qgis-developer] QEP - Proposal for QGIS 3.0 after 2.14
larrys at dakotacarto.com
Wed Oct 21 07:44:47 PDT 2015
On Tue, Oct 20, 2015 at 10:52 PM, Mathieu Pellerin <nirvn.asia at gmail.com>
> Great initiative! The sooner a plan can be agreed upon, the better.
> Coincidentally to your QEP proposal, I came up with an alternative
> timeline idea over the last few days that would avoid skipping a release
> cycle but still give us enough time to complete the port to Qt5.
> Basically, we begin the development cycle of both 2.14 LTR _as well as_
> 3.0 at the same time, following the public release of 2.12. The
> simultaneous overlapping development of those two versions (for the first
> four months) would have two distinct objectives and release dates:
> - for 2.14 LTR, the development cycle would last 4 months and would be
> released, as planned, on 26.02.2016 with a focus on stability and bugfix
> based on the feedback from users on 2.12 (small-ish new features could be
> pushed too)
> - for 3.0, the development cycle would last 8 months, with the first four
> months overlapping with the development of 2.14 LTR, and be released on
> 26.06.2016 (as our 4-month release cycle would have it following the
> release of 2.14 LTR) with a focus on porting QGIS to Qt5 and python 3 as
> well as significant new features.
> This alternate timeline proposal both speeds up the delivery of QGIS 3.0
> as well as insuring QGIS 2.14 LTR is shipped with a focus on stability as
> devs can push new features onto QGIS 3.0.
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.'
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. 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
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.
Black Hills, South Dakota
> On Wed, Oct 21, 2015 at 10:30 AM, Nyall Dawson <nyall.dawson at gmail.com>
>> Hi all,
>> Thought I'd try and get things moving on this. Please see
>> for a QEP regarding QGIS 3.0 being the release after 2.14 and the
>> changes proposed for 3.0.
>> Feedback welcome!
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer