<div dir="ltr">> <span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Does the composer change require QGIS 3<br></span><br>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.<div><br></div><div>- Nathan</div></div><br><div class="gmail_quote">On Sat, 18 Apr 2015 at 00:32 Matthias Kuhn <<a href="mailto:matthias.kuhn@gmx.ch">matthias.kuhn@gmx.ch</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
For me the most important questions are:<br>
<br>
1. Does the composer change require QGIS 3 (not totally convinced
yet)?<br>
<br>
2. What should be the driver for QGIS 3?<br>
2a) External dependencies (E.g. Debian Jessie+1 is going to remove
Qt4 [1])<br>
2b) Internal changes (composer? low level things like feature API,
geometry, expression...)<br>
<br>
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).<br>
<br>
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<br>
<br>
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)<br>
<br>
Regards<br>
Matthias<br>
<br>
[1]
<a href="http://perezmeyer.blogspot.com.es/2014/11/early-announce-qt4-removal-in-jessie1.html" target="_blank">http://perezmeyer.blogspot.com.es/2014/11/early-announce-qt4-removal-in-jessie1.html</a></div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 04/17/2015 04:12 PM, Marco
Hugentobler wrote:<br>
</div>
<blockquote type="cite">
<div>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 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 href="mailto:madmanwoo@gmail.com" target="_blank">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 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 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 href="http://www.faunalia.eu" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" target="_blank">http://www.faunalia.eu/training.html</a><br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a 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></fieldset>
<br>
<pre>_______________________________________________
Qgis-psc mailing list
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a></pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a>
Technical Advisor QGIS Project Steering Committee </pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Qgis-psc mailing list
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div>