[Qgis-psc] Vote about release plan

[Matthias Kuhn]

For me the most important questions are:

1. Does the composer change require QGIS 3 (not totally convinced yet)?

2. What should be the driver for QGIS 3?
 2a) External dependencies (E.g. Debian Jessie+1 is going to remove Qt4 [1])
 2b) Internal changes (composer? low level things like feature API,
geometry, expression...)

If #1 is answered with a clear yes, do the change quick. (We could also
just do this change, label it with QGIS 3 which is almost 2.xx and
postpone the heavy lifting to a medium-term QGIS 4).

If #2a is the answer let's keep releasing 2.xx versions with no/minor
API breaks and risk that we'll have to do a quick move once a platform
obsoletes a dependency

If #2b is answered with a yes, define a date/2.xx version (e.g. one year
from now) where QGIS 3 will be released so there is time to think of
other spring cleaning jobs that can be put there and discuss these.
(This is my favorite)

Regards
Matthias

[1]
http://perezmeyer.blogspot.com.es/2014/11/early-announce-qt4-removal-in-jessie1.html

On 04/17/2015 04:12 PM, Marco Hugentobler wrote:
> But then can we make an official decision that we are not going to 3
> before version 2.xx (xx still to be decided). And related to that also
> no PyQt5 / python3 before that version. My concern was that there
> might be another API breaking release shortly after the composer API
> breaks (and there are plugins using the composer API). That's why I
> proposed a fast move. But if it is guaranteed to be stable for a
> longer period after the composer breaks, that's fine too.
>
> Regards,
> Marco
>
> On 17.04.2015 15:51, Nathan Woodrow wrote:
>> So in the end all this comes down to is: When are we going to be
>> forced to break API because of a platform change that we can't control? 
>>
>> From what I can see it's a while off.
>>
>> P.S I have no issue, and I doubt users do, with 2.10, 2.12. 2.14. We
>> never really have to go to 3 if there is no need.
>>
>> - Nathan
>>
>> On Fri, 17 Apr 2015 at 20:35 Nathan Woodrow <madmanwoo at gmail.com
>> <mailto:madmanwoo at gmail.com>> wrote:
>>
>>     > What is the main problem in breaking APIs? AFAIK is the need to
>>     fix the
>>     plugins.
>>
>>     Not just plugins but every script that anyone has written against
>>     the QGIS API which can be a lot of internal scripts and
>>     processes.  It really comes down to just a pain if it's not
>>     justified or needed.   If we are forced to Python 3 and PyQt5
>>     then it's a different story because we didn't really have much
>>     choice but all platforms will have to move it will be a nightmare
>>     having to maintain PyQt5/Python3+PyQt4/Python2.7 plugins and scripts.
>>
>>     - Nathan
>>
>>     On Fri, 17 Apr 2015 at 20:17 Paolo Cavallini
>>     <cavallini at faunalia.it <mailto:cavallini at faunalia.it>> wrote:
>>
>>         Il 17/04/2015 09:51, Radim Blazek ha scritto:
>>         > On Thu, Apr 16, 2015 at 8:43 PM, HAUBOURG
>>         > <regis.haubourg at eau-adour-garonne.fr
>>         <mailto:regis.haubourg at eau-adour-garonne.fr>> wrote:
>>         >> Hi,
>>         >> again, I really can't understand squeezing the very next
>>         release now, a month before feature freeze.
>>         >>
>>         >> For a major break, good practices should be:
>>         >>  - announce it publicly at least two minor versions before
>>
>>         +1
>>
>>         >>  - finish old branch on a LTR version and announce it so
>>         that feature are not added in that branch
>>
>>         +1 (this is a good reason to have 2.8 followed by 3)
>>
>>         >>  - not break API too often. 2.0 was.. less than two years ago.
>>
>>         This would be good, but I'm afraid is partly outside of our
>>         control
>>         (libray update by major distros).
>>         What is the main problem in breaking APIs? AFAIK is the need
>>         to fix the
>>         plugins. IMHO we should avoid leaving plugin authors alone;
>>         providing
>>         detailed instructions on how to upgrade the plugin, and if
>>         possible some
>>         scripts to fix most common cases, would make things less
>>         traumatic.
>>         Therefore I suggest evaluating this work, and investing in it.
>>         All the best.
>>
>>
>>         --
>>         Paolo Cavallini - www.faunalia.eu <http://www.faunalia.eu>
>>         QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>         _______________________________________________
>>         Qgis-psc mailing list
>>         Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>>         http://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
> -- 
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee 
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20150417/0070e2b5/attachment.html>