<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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.<br>
      <br>
      Regards,<br>
      Marco<br>
      <br>
      On 17.04.2015 15:51, Nathan Woodrow wrote:<br>
    </div>
    <blockquote
cite="mid:CAAi8Yg-c-R0wM4Piyk_4OTXvGK+pptJYRZKGEObb5zgaCk+VwQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">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? 
        <div><br>
        </div>
        <div>From what I can see it's a while off.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>- Nathan<br>
          <div><br>
            <div class="gmail_quote">On Fri, 17 Apr 2015 at 20:35 Nathan
              Woodrow <<a moz-do-not-send="true"
                href="mailto:madmanwoo@gmail.com">madmanwoo@gmail.com</a>>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div dir="ltr">> <span
                    style="font-size:13.1999998092651px;line-height:19.7999992370605px">What
                    is the main problem in breaking APIs? AFAIK is the
                    need to fix the</span><br
                    style="font-size:13.1999998092651px;line-height:19.7999992370605px">
                  <span
                    style="font-size:13.1999998092651px;line-height:19.7999992370605px">plugins.</span><br>
                  <div><span
                      style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br>
                    </span></div>
                </div>
                <div dir="ltr">
                  <div><span
                      style="font-size:13.1999998092651px;line-height:19.7999992370605px">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.</span></div>
                </div>
                <div dir="ltr">
                  <div><span
                      style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br>
                    </span></div>
                  <div><span
                      style="font-size:13.1999998092651px;line-height:19.7999992370605px">-
                      Nathan</span></div>
                </div>
                <br>
                <div class="gmail_quote">On Fri, 17 Apr 2015 at 20:17
                  Paolo Cavallini <<a moz-do-not-send="true"
                    href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">Il
                    17/04/2015 09:51, Radim Blazek ha scritto:<br>
                    > On Thu, Apr 16, 2015 at 8:43 PM, HAUBOURG<br>
                    > <<a moz-do-not-send="true"
                      href="mailto:regis.haubourg@eau-adour-garonne.fr"
                      target="_blank">regis.haubourg@eau-adour-garonne.fr</a>>
                    wrote:<br>
                    >> Hi,<br>
                    >> again, I really can't understand squeezing
                    the very next release now, a month before feature
                    freeze.<br>
                    >><br>
                    >> For a major break, good practices should
                    be:<br>
                    >>  - announce it publicly at least two minor
                    versions before<br>
                    <br>
                    +1<br>
                    <br>
                    >>  - finish old branch on a LTR version and
                    announce it so that feature are not added in that
                    branch<br>
                    <br>
                    +1 (this is a good reason to have 2.8 followed by 3)<br>
                    <br>
                    >>  - not break API too often. 2.0 was.. less
                    than two years ago.<br>
                    <br>
                    This would be good, but I'm afraid is partly outside
                    of our control<br>
                    (libray update by major distros).<br>
                    What is the main problem in breaking APIs? AFAIK is
                    the need to fix the<br>
                    plugins. IMHO we should avoid leaving plugin authors
                    alone; providing<br>
                    detailed instructions on how to upgrade the plugin,
                    and if possible some<br>
                    scripts to fix most common cases, would make things
                    less traumatic.<br>
                    Therefore I suggest evaluating this work, and
                    investing in it.<br>
                    All the best.<br>
                    <br>
                    <br>
                    --<br>
                    Paolo Cavallini - <a moz-do-not-send="true"
                      href="http://www.faunalia.eu" target="_blank">www.faunalia.eu</a><br>
                    QGIS & PostGIS courses: <a
                      moz-do-not-send="true"
                      href="http://www.faunalia.eu/training.html"
                      target="_blank">http://www.faunalia.eu/training.html</a><br>
                    _______________________________________________<br>
                    Qgis-psc mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:Qgis-psc@lists.osgeo.org"
                      target="_blank">Qgis-psc@lists.osgeo.org</a><br>
                    <a moz-do-not-send="true"
                      href="http://lists.osgeo.org/mailman/listinfo/qgis-psc"
                      target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
                  </blockquote>
                </div>
              </blockquote>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Qgis-psc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-psc@lists.osgeo.org">Qgis-psc@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-psc">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a></pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a class="moz-txt-link-abbreviated" href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a class="moz-txt-link-freetext" href="http://www.sourcepole.ch">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
  </body>
</html>