<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 15/09/2012 06:14, Kent James wrote:<br>
</div>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 9/14/2012 9:30 PM,
Unicorn.Consulting wrote:<br>
</div>
<blockquote cite="mid:50540461.5030406@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
<div class="moz-cite-prefix">On 15/09/2012 1:42 PM, Kent James
wrote:<br>
</div>
<blockquote cite="mid:50540047.4040003@caspia.com" type="cite">I
have an alternate proposal for the release planning. <br>
<br>
So my proposal is that we do "intermediate releases" to the
main release channel starting at either TB 22 or TB 23. These
would be releases from the main central/aurora/beta/release
repositories so would not need additional repos with all of
the complications of that. <br>
</blockquote>
</blockquote>
</blockquote>
Assuming these are based on the equivalent Gecko versions, then we
would also need to consider back-porting of the core security fixes
to those releases for each of the .0.1 releases.<br>
<br>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
<blockquote cite="mid:50540461.5030406@gmail.com" type="cite"> I
think that an ESR release should not become an ESR release at
the same time the general release occurs. ESR is really aimed at
Business and they are in no hurry for new releases, so we do
what business has been doing for almost as long as they have had
computers, wait for the .1 release. That is there will be a
17.1 ESR and a 24.1 ESR or whatever no time frame as such, but
released reasonably soon after the main release with fixes as
required, including a roleup of the now almost mandatory 0.1 and
0.2. Releases. The general user base can come along for the
ride to point one, but point one is the ESR release.<br>
</blockquote>
</blockquote>
ESR has been designed with new features at the time of the ESR being
considered. There is an overlap of 2 releases on the ESR channel to
allow organisations time to switch over and for any critical issues
to be resolved. The <a
href="http://www.mozilla.org/thunderbird/organizations/faq/">ESR
FAQ</a> has a diagram showing this overlap. Hence, this allows for
the .0.1 and .0.2 releases.<br>
<br>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite"> So
to interpret what I think you are saying in terms of repos and
channels, we proceed with 17.0 as planned - but it is not the ESR
release. We freeze mozilla-central in comm-aurora, release, and
beta so that eventually release, beta, and aurora are all on
gecko17. New work is landed in comm-central (with current gecko),
and selected patches are landed in aurora (with a+) as needed in
17.1 (which will also be ESR). After 17.1 releases, we restart the
central->aurora->beta migrations as now (but no new releases
until 24.0 then 24.1 ESR)<br>
</blockquote>
I think my other message to this thread covers this slightly
differently. What I think I could do with though, is a clear
statement of the problem you're trying to solve here, as this
doesn't just sound like just allowing an intermediate release of
features. Earlier in the thread you mentioned there's issues fixing
bugs due to L10n. Are these flagged as tracking-thunderbird17? Can
you also provide some examples?<br>
<br>
Thanks<br>
Mark.<br>
</body>
</html>