[Qgis-psc] Vote about release plan

Fri Apr 17 07:44:36 PDT 2015

> Does the composer change require QGIS 3

Nyall has told me this isn't the case anymore.  I'm sure he can add more
but I'm pretty sure it can just side by side until we remove the old stuff
later.

- Nathan

On Sat, 18 Apr 2015 at 00:32 Matthias Kuhn <matthias.kuhn at gmx.ch> wrote:

>  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> 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>
>> 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> 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
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> _______________________________________________
>>> Qgis-psc mailing list
>>> Qgis-psc at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>
>
> _______________________________________________
> Qgis-psc mailing listQgis-psc at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerlandmarco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
>
> _______________________________________________
> Qgis-psc mailing listQgis-psc at lists.osgeo.orghttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20150417/893da0b0/attachment.html>