[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