[Qgis-developer] Release schedule discussion - again

Mon Oct 12 13:33:15 PDT 2015

Hi

> On 12 Oct 2015, at 18:37, Andreas Neumann <a.neumann at 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 at lists.osgeo.org <mailto:Qgis-developer at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151012/829f3b36/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaLogo160x66.png
Type: image/png
Size: 9324 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151012/829f3b36/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151012/829f3b36/attachment-0001.sig>