Hi,
I am not part of the development of QGIS, but as a user, please consider
the following:
Currently every 3rd release of QGIS is billed as a Long Term Release.
So:
Switch this to February every Even numbered year
Yes, this thought is in line with Ubuntu LTS plans, and I am ware not
"everyone" uses Ubuntu,
But,
As someone who runs a production house, I have to keep both stability
and latest features in mind.
I run my servers on Ubuntu Server LTS, and know that I have a window of
opportunity to change every 2 years. With this is peace of mind, and I
can get on with the fun (read: bleeding edge) stuff, knowing that I will
not blow up my servers.
For those deploying QGIS in a production environment, such peace of mind
might also be welcome.
So rather than releasing an "LTR" version every 3rd release (which will
slip as the intermediate releases might slip), give the Enterprise users
a chance to plan their production installations using a calendar, and
not have to keep track of "Oh, is this the 2nd or 3rd release coming up???)
I chose the "Two months before Ubuntu LTS" because QGIS could either
hang their LTR onto "nothing", or coincide it in good time before
another reliable release date happens (and thus get the QGIS LTR into
the LTS repositories as well).
Just a thought.
Regards,
Zoltan
On 2014/11/10 06:57, Geo DrinX wrote:
Yes yes yes.
+1
but also +999 :)
Roberto
2014-11-10 2:27 GMT+01:00 Mathieu Pellerin <[email protected]
<mailto:[email protected]>>:
Guys,
The recent thread Nyall kick-started with his "QGIS 3.0?" email
got me to think about the eternal stability vs. development
dilemma it (re-)exposed through the conversation.
More specifically, it got me to brainstorm on the best way forward
for QGIS at this juncture and whether there's a way to accommodate
both the folks calling for a 2.8 LTS version, and others in need
for space to further develop and expand QGIS' capability.
And, I might just have found a way to do so. Here's the proposal,
in a couple of points:
- We make the 2.8 development cycle "fix and refinement"-only, and
reduce the cycle's length to 6 to 8 weeks;
- The reduced cycle will help everyone's focus on the above goal;
- We append the freed 8-10 weeks to the subsequent development
cycle, which would become QGIS 3.0;
- The expanded cycle will help give space to develop some of the
exciting features being cooked by developers (Nyall's Layouts,
Marco's Geometry redesign, etc.) and bulletproof those.
This, IMHO, caters to both groups demanding stability and space
for development. It doesn't discourage or delay too much the grand
scheme changes, and pushes out a 2.8 version focused on stability
through a shorter cycle focusing on delivering a perfected tool.
The above proposal does require a momentary lapse of the nice
4-month release cycle rhythm which the QGIS has successfully
maintained for three releases now. But, it might actually be
what's needed at this very time. Plus, the length of the two
cycles stays the same, 8 months.
Comments? I'm obviously particularly interested in what Jürgen has
to say :)
Cheers
Math
_______________________________________________
Qgis-developer mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
===========================================
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
GIS and Photogrammetric Services
P.O. Box 7, Muizenberg 7950, South Africa.
Mobile: +27-83-6004028
Fax: +27-86-6115323 www.geograph.co.za
===========================================
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
