<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/20/12 1:10 AM, Unicorn.Consulting
wrote:<br>
</div>
<blockquote cite="mid:505A50F5.9060809@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
So you guys aren't worried that 6 or 12 weeks would be very short to
gather feedback bubble it up and have things fixed ? I'd rather have
20 or 21 as a target train.<br>
<pre class="moz-signature" cols="72">--
@lhirlimann on twitter
<a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/Thunderbird:Testing">https://wiki.mozilla.org/Thunderbird:Testing</a>
my photos <a class="moz-txt-link-freetext" href="http://www.flickr.com/photos/lhirlimann/collections/">http://www.flickr.com/photos/lhirlimann/collections/</a></pre>
</body>
</html>