<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 20/09/2012 12:29 AM, Kent James
wrote:<br>
</div>
<blockquote cite="mid:5059DDB4.5010107@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
I have no real objection.<br>
<br>
<blockquote cite="mid:5059DDB4.5010107@caspia.com" type="cite"> <br>
:rkent<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
“Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.” Benjamin Franklin</pre>
</body>
</html>