[Qgis-developer] Stress about release plans

[Olivier Dalang]

+1 for Bo Victor's idea which seems a good compromise to avoid that painful
LTS version.

What about having no fixed duration for the bug fixing phase for that "
LTS"-ish" 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).

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 ?

Best regards,

Olivier




2014-07-22 17:17 GMT+02:00 Bo Victor Thomsen <bo.victor.thomsen at gmail.com>:

>  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
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140722/2128332b/attachment-0001.html>