<div dir="ltr"><br><div class="gmail_extra">Hi all, </div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-03 8:52 GMT+01:00 Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2 November 2017 at 22:08, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br></span>[...]<br>
But the alternatives are:<br>
<br>
1. Ship with composer, and keep exposing composer API. We'll be stuck<br>
with composer for the life of 2.x, and when layouts lands in 3.2 we'll<br>
end up with duplicate buttons for "new composer"/"new layout", or some<br>
option to switch the print backend from composer/layouts. Ouch! Not to<br>
mention that we'll be forced to carry around and maintain thousands of<br>
lines of old code for the next x years.<br>
<br>
2. Ship with composer in 3.0, but remove from bindings (e.g.<br>
<a href="https://github.com/qgis/QGIS/pull/5486" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>pull/5486</a>). Then after thaw I can merge<br>
layouts and drop all the composer code. Downside is no ability to<br>
script or have composer based plugins in 3.0. Upside is layouts lands<br>
with the new clean api in 3.2, and we can have a clean-start then.<br>
Another upside is the additional full cycle of testing for layouts<br>
which means that when it's available to users in 3.2 it should be<br>
rock-solid.<br>
<br>
That's me laying out all the options as I see them. I'm honestly happy<br>
to abide by whatever decision the release manager/PSC makes here. I<br>
don't envy their position in making this call (sorry!)<br><br></blockquote><div><br></div><div>Is there no option 3 "drop composer totally and merge layouts " ? It was the very first need that started QGIS3 project IIRC. </div><div><br></div><div>On our side, we will be severely impacted for short time project if we drop composer, but I think the mid term option with mixed composer and layout in QGIS will cost al lot more to all of us. Users won't understand having both, and not having python bindings to layout in 3.0 will be a no go for deploying applications. So that would be the same as tagging 3.0 as a release candidate version, which is not the path we chose. </div><div><br></div><div>Regards</div><div>Régis</div><div>  </div><div> </div></div></div></div>