<div dir="ltr">+1 for Bo Victor's idea which seems a good compromise to avoid that painful LTS version.<div><div><br></div><div>What about having no fixed duration for the bug fixing phase for that "<span style="font-family:arial,sans-serif;font-size:13px">LTS"-ish</span>" version, but releasing it only when there's no blocker left in the tracker ? (I'd find it strange to publish such a version with serious known bugs).</div>
<div><br></div><div>It's true that this may stuck QGIS's development for some time, but what's better than a stuck situation to convince sponsors that they have to give out some money, and to convince devs they have to focus on bug fixing ?</div>
<div><br></div><div>Best regards,</div><div><br></div><div>Olivier</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-22 17:17 GMT+02:00 Bo Victor Thomsen <span dir="ltr"><<a href="mailto:bo.victor.thomsen@gmail.com" target="_blank">bo.victor.thomsen@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>The release cycles has been discussed
on the developers list before without a clear resolution. <br>
<br>
First of all, I agree with Lene regarding the state of QGIS.
There should be a "LTS" version of QGIS as bug free as possible
with new features added only on a yearly basis. The current
situation makes it very difficult to create up-to-date
documentation, tutorials for university courses and mass roll-outs
of QGIS in organisations.<i> </i>And it becomes difficult to
thoroughly test a given version. <br>
<br>
Furthermore: Every new release contains - of course - new features
and bug fixes. But with the addition of new features you always
get some new bugs; both in the new features but occasionally in
some <u>existing, previously functioning</u> part of QGIS. This
makes QGIS look like a piece of shoddy work.<br>
<br>
A LTS version of QGIS would solve a large part of these problems<br>
<br>
On the other hand I do understand the regular, non-paid volunteer
developers ain't that keen to support a LTS version without some
monetary compensation. And that can be hard to obtain :-/<br>
<br>
I would suggest an alternative: <br>
<br>
The current release cycle look roughly like this:<br>
<ol>
<li>Development phase, 3 months of adding new features and bug
fixes to QGIS in a developer version of QGIS<br>
</li>
<li>Feature freeze, 1 month cleaning and polishing the developer
version, i.e. bug fixing the new features and removing old
bugs. Updating of translations. <br>
</li>
<li>Release of the developer version as the new stable version
of QGIS and start of a new developer version of QGIS</li>
<li>1 month of reporting and bug fixing the new stable release
and a probably a second minor release of the new version<br>
</li>
</ol>
Using the above cycle gives us 3 new "stable" versions each year
because point (1) and (4) overlaps.<br>
<br>
My suggestion is that<b> one</b> of the three version cycles is
replaced with the following:<br>
<ol>
<li>Development phase, <b>1</b> month of adding new features
and bug fixes to QGIS in a developer version of QGIS<br>
</li>
<li>Bug fixing only feature freeze, <b>3</b> months cleaning
and polishing the developer version, i.e. bug fixing the new
features and removing old bugs with <b>special care</b>
taken for finding and removing bugs introduced in the last two
cycles. Updating of translations.<br>
</li>
<li>Release of the developer version as the new stable version
of QGIS and start of a new developer version of QGIS</li>
<li><b>1</b> month of reporting and bugfixing the new stable
release and a with a <b>guaranteed</b> second minor release
of the new version.<br>
</li>
</ol>
This version could be used a "LTS"-ish version of QGIS for one
year at a time.
The result of this development cycle will probably:<br>
<ul>
<li>Have a very small amount of errors introduced in existing
features by adding new features to QGIS. (No shoddy parts in
QGIS :-)<br>
</li>
<li>It would be possible to introduce new features on a <b>minor</b>
scale in this development cycle<br>
</li>
<li>Have a large time window for bug fixing. </li>
<li>Let documenters, teachers and to some extend testers use
this version of QGIS for one year at a time. </li>
<li>No extra work with having two versions of QGIS to support at
the same time.<br>
</li>
</ul>
<br>
Regards <br><span class="HOEnZb"><font color="#888888">
<br>
Bo Victor Thomsen<br>
Aestas-GIS <br>
Denmark<br>
<br>
<br>
</font></span></div>
</div>
<br>_______________________________________________<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" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br></div>