<div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div><div>I also think 4 months is too frequent (users on gis.stackexchange are still reporting on 2.0 release!), but think anything longer than 6 months may be too long.<br>
</div><div><br></div>What about this scenario (building upon Nathan's suggestion)?<br><br></div>1)  4 full months of development on master branch (currently is only 3 months)<br><br></div>2)  1 month of testing RC (during feature freeze)<br>
<br></div>3)  Tag release (e.g. 2.6.0), do NOT create a release branch; then, package and release<br><br></div>4)  1 month (minus previous packaging/release time) of users testing release and devs working on fixes directly to master branch (still in feature freeze)<br>
<br></div>5)  Tag bug fix release (e.g. 2.6.1), create new branch for 'release-2_6'; then, package and do single bugfix release<br><br></div>6)  Repeat from 1), with any new fixes backported to 'release-2_6' branch, when resources/funding allow<br>
<div><br><br></div><div>This allows for a decent amount of development time for new features, and a good amount of time for testing (both as a RC and after the public release). The 'stable' branch is not created until the bugfix release, thereby keeping all devs/testers focused on fixes directly to master branch.<br>
<br></div><div>Essentially, it is a 6-month release cycle with a single bugfix release (if needed) guaranteed to happen 1 month after initial release. The release branch remains open to backported fixes, but packagers should only expect/schedule to do one 'official' followup bugfix release. Any further bugfix releases would be at the packagers discretion.<br>
</div><div><div><div><div><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">IMO, this may increase dev work on stability, while not detracting from the forward momentum of development and not forcing maintenance of multiple branches, unless sponsors step up to provide such help.<br>
<br></div><div class="gmail_extra">It will also show due diligence on the part of the dev team to focus on user-reported bug fixes directly after the public release.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Regards,<br clear="all"></div><div class="gmail_extra"><div><br>Larry</div>
<br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 4:44 AM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Good to hear that there are organizations putting money into QA. Thanks<br>
a lot.<br>
<br>
I think there are different categories of users, experimental early<br>
adopters and organizations going for stability at the expense of<br>
waiting longer for new features.<br>
<br>
To get the best for both, LTS releases may be a good option. One LTS<br>
branch every 8 or 12 months which gets fixes backported and 1 or 2<br>
other releases in between which work the way we currently have it.<br>
<br>
Advantages are<br>
New features get tested in the in-between releases (they will get used<br>
because they are not called experimental or testing or rc).<br>
Big organizations use the same LTS release (in comparison to the<br>
general advice of "take every second release" which will bring one org<br>
to use the Jun release and the other one the Feb release) and can<br>
collaborate with bugfixing<br>
Backports of bugfixes have always to be done for one specific/defined<br>
version. (In comparison: if a company skips release 2.6 they are still<br>
with 2.4 in the 2.7 period, and nobody will backport to 2.4 at that<br>
stage)<br>
<br>
Best,<br>
Matthias<br>
<div class="im"><br>
On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote:<br>
> Il 19/06/2014 12:19, Andreas Neumann ha scritto:<br>
><br>
>> I'd like to add to the discussion that there will be more organizations<br>
>> investing in bug-fixing in the future. Yesterday, a Swiss canton told me<br>
>> that they will invest 5000 CHF each year in QA/bugfixing in the future.<br>
>> I am pretty sure that more organizations will follow.<br>
><br>
> Wonderful, this is the way to go IMHO.<br>
><br>
>> But it is important that we will provide bug-fix releases and that there<br>
>> is a reasonable time available for testing. The short releases do not<br>
>> help at all for organizations - because each new release introduces more<br>
>> and different bugs.<br>
><br>
> The above mentioned resources could be used for maintaining a stable branch, and<br>
> backporting.<br>
><br>
>> We users need bug-free software more than a predictable release date. We<br>
>> don't need QGIS at an exact specific time. But we cannot accept that<br>
>> some features are broken that are key to our work.<br>
><br>
> Agreed fully: that's what Blocker category is for.<br>
> All the best, and thanks for this important discussion.<br>
><br>
<br>
<br>
</div><div class=""><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div></div>