Hi
> On 12 Oct 2015, at 18:37, Andreas Neumann <a.neum...@carto.net> wrote: > > Hi Jürgen, > > I don't claim that a six months release schedule solves all our issues. I > know it is not too different. > > But every release is a lot of work - for packagers, translators, testers, > documenters - also for people like Anita and me who help > evangelizing/promoting QGIS. In the past I tried to promote/advertise QGIS > for every release - now it became insane - it would be a full-time job! > > There was probably a reason to release very often in the early days of QGIS - > when a lot of features were still missing - but there is not so much pressure > anymore these days. > > I also have the impression that our testing/bug fixing period is too short. > If I am on holidays for 1-2 weeks during this time, I almost missed my > opportunity to properly test the release. It would be much easier if it would > be a 2-month period for testing/bug fixing. > > And there is another thing: I usually tell the Swiss QGIS users to test a new > release - if this happens too often - they don't take you seriously anymore - > What? There was just a release a couple of weeks ago - and now I should > already test again? The reality is that many users out there work with old > releases because they can't upgrade that often - due to whatever reasons in > their organizations. > > Like Régis - even if my users may only work with the LTR version - I > personally want to stay up-to-date/current with the in between releases - > test stuff early on. For me, personally, even the nightly is good enough for > the testing purpose. No need to do a full release for testing stuff. But if > it happens that feature X only works in version A, and then stops working in > the next release due to a bug, and then yet another feature only worked in > the version 2 versions ago - it really becomes a burden and nightmare to > maintain QGIS in an organization. > > If we continue cranking out releases at this very fast pace - we also risk a > very strong disconnect between the actual professional users out there (who > may be 2-4 releases behind) and the nerds who can afford to stay always at > the cutting edge. > > And: we could better concentrate our quality assurance efforts and finances > (employ more devs and/or let them work longer/more concentrated on bug > fixing) if we don't release too often. Andreas how would you see the LTR releases working in relation to a slower release cycle? I have thought at times that we should make the LTR’s longer lived e.g. 2 years (1 year is not really that ‘long term’). Regards Tim > > Andreas > > On 12.10.2015 17:49, Jürgen E. Fischer wrote: >> Hi Andreas, >> >> On Mon, 12. Oct 2015 at 13:47:03 +0200, Andreas Neumann wrote: >>> I know - this discussion came up repeatedly in the past - but here I >>> am, bringing it up again. Jürgen - please don't shoot me ;-) >> As if that would help - there are far too many people out there ;) I just >> wonder why this needs to be discussed again shortly before a release. >> >> And I don't actually see any new points - this has been discussed before and >> I >> never saw any striking arguments that would really make it clear that four >> months is too short, while six months would be all that different. >> >> That the initial LTR release wasn't any different from the other releases >> stability-wise is correct. But should it? We maintain it for a year - and >> that's the difference. >> >> That bugs pop up shortly after the release is probably unavoidable unless it >> gets intensive testing. Otherwise the people testing (although they >> probably >> just want to use) a new release will easily outnumber the people testing and >> fixing it before the release and hence might find serious things right after >> the release - or even before we have all the packages ready. >> >> I guess that's why we always had point releases right after the .0 releases >> and >> I don't think that will change with a switch to a six month schedule. >> >>> As a QGIS user in government (you could also replace this by a company or >>> other professional users) I find the 4 month release schedule not ideal - >>> and >>> quite stressful. I would rather prefer a half-year or yearly release and >>> then >>> proper bug-fix releases. I also find the one month window for testing/bug >>> fixing too short. >> For those there is the LTR. That's who we make it for. If not even those >> are >> using it, why do we make it at all? >> >> You might say that you can't wait twelve month for new features you fund. >> Right, and that's why the release schedule is as short as it is. It's to >> make >> new features available in a release relatively quickly. But if it's four or >> six month isn't a big difference there either. >> >> If we released every 6 months, how long would we maintain the LTR? Still a >> year and every second release is a LTR? Or still every third release? >> >> I don't really care that much if we release on a four or six month schedule >> (ubuntu does six monthly releases too). >> >> >> Jürgen >> >> >> >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> <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 — Tim Sutton Visit http://kartoza.com <http://kartoza.com/> to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net Tim is a member of the QGIS Project Steering Committee Kartoza is a merger between Linfiniti and Afrispatial
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
