+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.thom...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
