<div dir="ltr"><div>Thanks Nyall for raising this. <br></div><div>This indeed fells like "deja vu" and we need to advertise users that a fresh new major release will for sure need point releases. We didn't probably explain well enough that 3.4 is the LTR candidate, but will definitly be a LTR in january at the end of life of 2.18 version.<br></div><div><br></div><div>I am a big +1 on a code freeze period. This code freeze period will need to be associated with a strict definition of "blocker issues" that really need to by adressed immediatly. This issue here is a great example of a valid blocker.</div><div>  <br></div><div>I also think we have now a large enough code base and user base to prepare a slower release cycle with longer feature freeze, bugfix  and code freeze. We talked about it in Zanzibar, and I think advertising now that by the end of 2019, ltr should be supported for 2 years, and releases every 6 months would be nice. <br></div><div><br></div><div>What worries me in current fast cycle is that we have a lot of packaging burden for all OS, and each release has a human cost. I think it's time we just slow down just a little, but 6 months would already be something really fast for such a big software in fact.  <br></div><div><br></div><div>Cheers</div><div><br></div><div>Régis<br></div><div><br></div><div> <br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 31 oct. 2018 à 10:12, Giovanni Manghi <<a href="mailto:giovanni.manghi@gmail.com">giovanni.manghi@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nyall, all,<br>
<br>
<br>
> Soo.... could we break the normal cycle and get a point release out<br>
> quickly? (Ideally with a couple of days prenotice so that anyone else<br>
> working on urgent bug fixes could get them in too)<br>
<br>
there are also two major issues with Processing/GRASS (tools not<br>
working when windows regional settings are not set to English and also<br>
not working for any multilayer datasource like gpkg), this is for many<br>
a blocker for the process of adopting QGIS 3 LTR over 2.18.<br>
<br>
cheers!<br>
<br>
-- g --<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>