<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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>
<br>
Bo Victor Thomsen<br>
Aestas-GIS <br>
Denmark<br>
<br>
<br>
</div>
</body>
</html>