<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 8/4/2011 8:32 AM, Mark Banner wrote:
<blockquote cite="mid:4E3ABB88.10400@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Something I know we've been missing since switching to the rapid
release process, is a document saying what we are doing and how we
are going to be working, reflecting the documents that <a
moz-do-not-send="true"
href="http://mozilla.github.com/process-releases/">Firefox wrote</a>.<br>
<br>
I've now drafted the document and welcome feedback and discussion
on it:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://people.mozilla.org/%7Embanner2/tbdevspecifics/">http://people.mozilla.org/~mbanner2/tbdevspecifics/</a><br>
<br>
</blockquote>
Overall, an excellent document. My only requests are that you add a
plan for the timing of increments of the allowable Thunderbird
revisions on AMO, and that you be explicit about the allowable
timing of changes to interfaces.<br>
<br>
For me, the AMO revision allowed is still an issue that is not
being done as I would wish. A binary extension such as mine should
ideally do their version updates in the aurora time scale and get
reviewed (all of which can take many weeks), so that it is ready for
use when beta comes out. (Of course this is only doable if you are
disciplined about not doing interface changes late in the aurora
timescale). So when beta releases, AMO should already be allowing
compatibility with it. But right now for example, with aurora at 7,
7.0 is not an allowed AMO TB version. A binary extension does not
want to declare compatibility with the allowed 8.0a1. If you wait
until after beta is released to update AMO, then at the (automatic)
user beta updates, your extensions are guaranteed to be
incompatible, regardless of how diligent the extension author is.<br>
<br>
rkent<br>
</body>
</html>