<div dir="ltr">Stable releases matter because we try to guarantee that things will not regress from one stable release to the next.  The "best" way to do this is to have good enough unit tests such that things don't regress at all, of course, but that's unfeasible.<div><br></div><div>One good indicator we should probably start the stable release process is if a significant amount of users are following the beta channel because they expect it to be "better" than the stable channel, which of course depends on which app they want to run.  This is a moving target, which implies our decision to start the overhead of another stable release should have something to do with the current state of the world for real human users -- that is, in a hypothetical world where wine1.7 was exactly as different from wine1.6 as it was today, but most users are happily running apps that already work on wine1.6, we could more comfortably delay a release.</div><div><br></div><div>Wine1.6 was pretty good a few years ago, but if we're serious about users, we should probably start seriously talking about Wine1.8.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 12:18 PM, Francois Gouget <span dir="ltr"><<a href="mailto:fgouget@free.fr" target="_blank">fgouget@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 10 Feb 2015, Jerome Leclanche wrote:<br>
[...]<br>
<span class="">> The problem of the "Stable" vs "Develop" distinction is kind of lost<br>
> in a model like Wine's. Users care about things being stable because<br>
> they don't want what they currently use to break. However, since Wine<br>
> is always playing catch-up to Windows, you have a lot of bits which<br>
> are *broken* and get taken care of in further dev releases. So the<br>
> usual view that "stable is good, master is buggy" is completely wrong<br>
> and it's not an easy thing to explain to users.<br>
<br>
</span>Users care that the application they are using does not stop working and<br>
that's what can happen with the development branch. So the distinction<br>
between stable and development branches does make sense.<br>
<br>
And just like in other projects you can be forced to use a development<br>
version because of compatibility issues with your hardware or of a<br>
feature you absolutely need, in Wine you can be forced to use the<br>
development version because of compatibility issues with your Windows<br>
applications.<br>
<br>
So really the stable / development distinction is no different in Wine<br>
than in other projects.<br>
<br>
The only thing that sets Wine apart is that it evolves pretty fast and<br>
yet has very infrequent stable releases. Hence these problems.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Francois Gouget <<a href="mailto:fgouget@free.fr">fgouget@free.fr</a>>              <a href="http://fgouget.free.fr/" target="_blank">http://fgouget.free.fr/</a><br>
                Linux: It is now safe to turn on your computer.<br>
<br>
<br>
</font></span></blockquote></div><br></div>