[Qgis-developer] Stress about release plans

Bo Victor Thomsen bo.victor.thomsen at gmail.com
Tue Jul 22 08:17:43 PDT 2014


The release cycles has been discussed on the developers list before 
without a clear resolution.

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.//And it 
becomes difficult to thoroughly test a given version.

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 _existing, 
previously functioning_ part of QGIS. This makes QGIS look like a piece 
of shoddy work.

A LTS version of QGIS would solve a large part of these problems

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 :-/

I would suggest an alternative:

The current release cycle look roughly like this:

 1. Development phase, 3 months of adding new features and bug fixes to
    QGIS in a developer version of QGIS
 2. Feature freeze, 1 month cleaning and polishing the developer
    version, i.e. bug fixing the new features and removing old bugs.
    Updating of translations.
 3. Release of the developer version as the new stable version of QGIS
    and start of a new developer version of QGIS
 4. 1 month of reporting and bug fixing the new stable release and a
    probably a second minor release of the new version

Using the above cycle gives us 3 new "stable" versions each year because 
point (1) and (4) overlaps.

My suggestion is that*one* of the three version cycles is replaced with 
the following:

 1. Development phase, *1* month of adding new features and bug fixes to
    QGIS in a developer version of QGIS
 2. Bug fixing only feature freeze, *3* months cleaning and polishing
    the developer version, i.e. bug fixing the new features and removing
    old bugs with *special care* taken for finding and removing bugs
    introduced in the last two cycles. Updating of translations.
 3. Release of the developer version as the new stable version of QGIS
    and start of a new developer version of QGIS
 4. *1* month of reporting and bugfixing the new stable release and a
    with a *guaranteed* second minor release of the new version.

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:

  * Have a very small amount of errors introduced in existing features
    by adding new features to QGIS. (No shoddy parts in QGIS :-)
  * It would be possible to introduce new features on a *minor* scale in
    this development cycle
  * Have a large time window for bug fixing.
  * Let documenters, teachers and to some extend testers use this
    version of QGIS for one year at a time.
  * No extra work with having two versions of QGIS to support at the
    same time.


Regards

Bo Victor Thomsen
Aestas-GIS
Denmark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140722/17e13f73/attachment.html>


More information about the Qgis-developer mailing list