[Qgis-psc] Vote about release plan

[Marco Hugentobler]

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

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