<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 9/19/2012 1:31 AM, Mark Banner
wrote:<br>
</div>
<blockquote cite="mid:505982E0.7060808@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 18/09/2012 17:03, Kent James
wrote:<br>
</div>
<blockquote cite="mid:50589B36.3070609@caspia.com" type="cite">
<div class="moz-cite-prefix"><br>
</div>
I think that the concern that Matt and I are showing is that
each new *. release seems to come with a few new critical issues
that are not resolved until the *.0.1 or *.0.2 release.
Currently ESR 17 is the same as TB17 and has the same initial
instability.<br>
<br>
Why is that needed? Why not delay the ESR release relative to
the main release until some period of time has elapsed for those
instabilities to get worked out? ESR has no rush to it.<br>
</blockquote>
I can understand the concern, but I don't believe it is really
critical to ESR. Despite our mentions about testing the changes,
I'm pretty sure some organizations won't start widely testing
until the next ESR is actually released. So if there are issues
that affect them specifically, they may not get reported until we
release the ESR. If we delayed releasing that ESR for a couple of
point releases, then they would be in the case where the old ESR
version would be unsupported, but they might not be able to
upgrade to the new version due to the issues.<br>
<br>
The overlap is there for exactly this reason - upgrade straight
away if you can, but if not, you've got 12 weeks to resolve any
issues (or get us to resolve them).<br>
</blockquote>
That's a good point. I had not thought of the issues of the overlap.
<br>
<blockquote cite="mid:505982E0.7060808@mozilla.com" type="cite"> <br>
<blockquote cite="mid:50589B36.3070609@caspia.com" type="cite">The
problem we are trying to solve is preventing the *.0.0
instabilities from hitting the ESR channel, so that ESR users do
not have to go through a period of pain before the release
stabilizes. Matt's proposal does this better than my initial
proposal.<br>
</blockquote>
Something else to point out here I think, is that when we release
ESR 17.0, only syadmins that choose to upgrade their uses to the
new ESR version will do so. As there will be two more ESR 10.0
releases (one in sync with ESR 17, the second in sync with
17.0.1), I don't see us prompting 10.0 users to do a major upgrade
until 17.0.2 is released and 10.0.x is obsolete.<br>
</blockquote>
OK that's news to me, thanks for pointing that out.<br>
<br>
With this discussion, I think that I am going back to my earlier
position, that the best way to use an intermediate release would be
to release a Thunderbird 23 or 22, so that we would get some
additional user feedback on issues before we get locked in for
another year.<br>
<br>
What do you think, Matt?<br>
<br>
:rkent<br>
</body>
</html>