<div dir="ltr">Hi all,<div><br></div><div>Now each LTR release is not that different from regular releases. Those</div><div>LTR releases don't get that much more testing than other releases and</div><div>the .0 releases are potentially as fragile as regular releases.</div><div>It is mostly the new features that cases bugs and crashes. What if we </div><div>don't introduce any new features in LTR releases?</div><div>This is just a thought and I don't know if it would work in practice.</div><div><br></div><div>Let me explain better what I mean with this.</div><div>Basically the last point release would come the next LTR-release. We could </div><div>still have three releases per year. If I use ubuntu release </div><div>notation those are 15.02, 15.06 and 15.09. The next LTR would be </div><div>released in February of 2016 and that would be based on 15.09.2 </div><div>for example. Lets name that release just LTR 16.</div><div>With this release process each new feature in LTR would have gone </div><div>through a three months testing during the usage period of 15.09 besides </div><div>the 15.09 feature freeze testing.</div><div>At the same time a regular 16.02 release could be released with all new </div><div>fancy features. Actually this would make four releases per year + point releases.</div><div><br></div><div>Is this kind of process proposed before?</div><div>Like I said before I don't know how would this work in practice because I</div><div>can't imagine all different bug fixing, back porting or packaging situations.</div><div><br></div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Lauri</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 9:46 AM, Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<span class=""><br>
Il 13/10/2015 01:14, Tom Chadwin ha scritto:<br>
> If the devs need more end users to test, then changing to a release every<br>
> six months, LTR every two years, would help. However, how would the devs<br>
> feel about patching LTRs for twice the duration they do now, and for one<br>
> extra non-LTR in between each? To me it sounds like significantly more work<br>
> to keep backporting for two years instead of one.<br>
<br>
</span>the current LTR has been an experiment, and IMHO it has been a success.<br>
Do we really want to change schedule every 6 months?<br>
We know for sure there are contrasting needs, and we'll never make<br>
everyone happy. Some times ago, we had people complaining not being able<br>
to use for many months the supercool feature they have developed or paid<br>
for.<br>
I think it's mostly a matter of communicating appropriately:<br>
* for maximum reliability, use the LTR<br>
* if you need latest features, go for the latest published.<br>
Maybe we should state this clearly on the download page.<br>
On the other hand, I am with Nyall on the Qt5 (and I should add Python<br>
3) issue.<br>
<br>
More below.<br>
<span class=""><br>
Il 12/10/2015 23:17, Larry Shaffer ha scritto:<br>
<br>
> At Boundless we are seeing both sides of the issue: users who want only<br>
> the LTR and users who deploy the LTR but always work with or test the<br>
> latest version between deployments of the LTR. The latter group is<br>
> finding the current pace quite difficult to keep up with. I'm talking<br>
> about very large government agencies rolling out to 100s upon 100s of<br>
> thousands of users. They rely upon the advice of their power users who<br>
> are working with whatever is the current version (not just the LTR).<br>
<br>
</span>This touches a *very* imprtant point: large organisations should have<br>
very clear that if they need a more stable release cycle, the best and<br>
most clever thing they should do is to fund:<br>
* more automated tests<br>
* more backfixing<br>
* more and earlier backporting.<br>
I cannot believe someone using any software in such huge numbers not<br>
having a few hundreds thousands bucks to properly support these needs.<br>
<br>
All the best.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/training.html</a><br>
All the best.<br>
--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/training.html</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div></div></blockquote></div><br></div>