<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 11, 2015 at 1:56 PM, Rosanne DiMesio <span dir="ltr"><<a href="mailto:dimesio@earthlink.net" target="_blank">dimesio@earthlink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, 11 Feb 2015 21:18:46 +0100 (CET)<br>
Francois Gouget <<a href="mailto:fgouget@free.fr">fgouget@free.fr</a>> wrote:<br>
<br>
<br>
> Users care that the application they are using does not stop working and<br>
> that's what can happen with the development branch.<br>
><br>
<br>
</span>That happens in the stable branch, too: when a new major stable release comes out, everything in the development branch goes into it, including unfixed regressions and bugs introduced by new features. The promise of "safe bugfixes only" only applies to minor releases in the stable branch, and most inexperienced users don't realize that.<br> </blockquote><div><br></div>To be clear, the whole concept of the "release process" is to generally switch our focus to removing all known regressions and to be even more conservative about introducing code that might cause regressions.  By way of comparison, there were only 1 or 2 user-visible regressions going from 1.0 to 1.2, whereas there were something on the order of several hundred at some point between 1.0 and each of the 1.1.x releases.</div></div></div>