[Qgis-developer] Release schedule discussion - again
larrys at dakotacarto.com
Mon Oct 12 14:17:39 PDT 2015
Hi Jürgen and all,
On Mon, Oct 12, 2015 at 9:49 AM, Jürgen E. <jef at norbit.de> 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.
Really? This thread is full of frustrations like:
* now it became insane
* barely usable for professional users
* risk a very strong disconnect between the actual professional users
* risk that their project doesn't load properly anymore
* big features are introduced without QEP's written
* more overhead, which leads to fewer time to test
* not able to review all the pending PR's
from *exactly the people* who work hard to introduce and support QGIS
within enterprise, government and educational institutions, which now
How are these not compelling arguments?
At Boundless we are seeing both sides of the issue: users who want only the
LTR and users who deploy the LTR but always work with or test the latest
version between deployments of the LTR. The latter group is finding the
current pace quite difficult to keep up with. I'm talking about very large
government agencies rolling out to 100s upon 100s of thousands of users.
They rely upon the advice of their power users who are working with
whatever is the current version (not just the LTR).
In other words, it is not a "one or the other" type deployment situation
for many enterprise rollouts. The LTR *compliments* the normal releases,
which are now too frequent and unstable.
Ideally, something needs to slow down and more effort focused on testing to
address these issues. After all, such large deployments are often where
funding comes from to add features or fix bugs (or keep some of us employed
> 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
> gets intensive testing. Otherwise the people testing (although they
> just want to use) a new release will easily outnumber the people testing
> fixing it before the release and hence might find serious things right
> 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
> > 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
> 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
> new features available in a release relatively quickly. But if it's four
> 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).
OK, then... I think the idea of 6 months between releases (with 4 for dev
and 2 for testing, and an LTR release once per year) sounds like a very,
very good solution to try.
Black Hills, South Dakota
QGIS Support/Development | Boundless <http://boundlessgeo.com/>
lshaffer at boundlessgeo.com
> Jürgen E. Fischer norBIT GmbH Tel.
> Dipl.-Inf. (FH) Rheinstraße 13 Fax.
> Software Engineer D-26506 Norden
> QGIS release manager (PSC) Germany IRC: jef on FreeNode
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer