<div dir="ltr">Hi,<div><br></div><div>After reviewing the release schedule recently put forward [0], I notice a discrepancy between what the project has advertised (1 year LTRs for 2.x) and when the upcoming LTRs are to released/packaged. Here is the schedule, pruned of non-relevant dates (with one proposed new packaging date for 2.14):</div><div><br></div><div><div>LTR 2.14.0 Mar 01, 2016</div><div><br></div><div>LR 2.16.0 Jul 22, 2016 (2.14 LTR packaged)</div><div><br></div><div>LR 2.18.0 Nov 08, 2016</div><div><br></div><div>LTR 2.18.7 May 19, 2017</div><div><br></div><div>*PR 2.18.9 Jul 21, 2017 (2.18 LTR packaged - proposed)</div><div><br></div><div>FF (2.99) Aug 18, 2017</div><div><br></div><div>LR 3.0.0 Sep 29, 2017 (2.18 LTR packaged - current)</div><div><br></div><div>FF (3.1) May 18, 2018</div><div><br></div><div>LTR 3.2.0 Jun 29, 2018</div><div><br></div><div>LR 3.4.0 Oct 26, 2018 (3.2 LTR packaged)</div><div><div class="gmail_signature"><div dir="ltr"><br></div><div>What this shows is that the lifespan of 2.14 was extended by just over two months. While two months may not seem that long, is there a reason for not packaging the 2.18 LTR twelve months after 2.14 LTR packaging?</div><div><br></div><div>Besides sticking with the advertised 1 year for 2.x LTRs, changing the *packaging-only* release date for 2.18 to Jul 21, 2017 offers these advantages:</div><div><br></div><div>* Project management of the 2.x branches can be closed out a month prior to the FF on 2.99. This keeps focus of release on the move forward to 3.0.0, instead of mixing 2.x and 3.x releases, i.e. a clean break from 2.x releases, making 3.0.0 the only focus when it is released.</div><div><br></div><div>* Regressions and bugs for 2.18 LTR, as reported by Giovanni [1], may not get fixed if project focus is split between the 3.0.0 FF/release and 2.18 release. Keeping the community focused on finishing up problems with 2.x and then 100% focus on 3.0.0, prior to the FF, avoids any split in limited dev resources.</div><div><br></div><div>I do see the balance provided by the Sep 29, 2017 packaging date for 2.18 LTR: 14 months since 2.14 packaging and 13 months until 3.2 packaging. However, the 2.x releases really do not need 'tied' to the 3.x releases in any way. Having 15 months between 2.18 and 3.2 is more reasonable than extending the time current LTR users have to wait for 2.18 LTR packages.</div><div><br></div><div>Opinions on proposed change of 2.18 packaging-only date? Please note: this suggests no change whatsoever with the 3.x release schedule.</div><div dir="ltr"><br></div><div dir="ltr">[0] <a href="http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule">http://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule</a></div><div dir="ltr">[1] <a href="http://osgeo-org.1560.x6.nabble.com/bug-tracker-cleanup-td5311756.html">http://osgeo-org.1560.x6.nabble.com/bug-tracker-cleanup-td5311756.html</a></div><div dir="ltr"><br></div><div>Regards,</div><div dir="ltr"><br>Larry Shaffer<br>----------------------------------<br>Boundless Desktop and QGIS Support/Development<br>Boundless Spatial - <a href="http://boundlessgeo.com" target="_blank">http://boundlessgeo.com</a><br><a href="mailto:lshaffer@boundlessgeo.com" target="_blank">lshaffer@boundlessgeo.com</a></div></div></div>
</div></div>