<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 11.05.2010 18:51, Ben Bucksch wrote:
<blockquote cite="mid:4BE98B18.2030001@beonex.com" type="cite"> I
think these are all great ideas. Thanks for moving forward on
this.
<br>
<br>
One point, though:
<br>
<br>
On 11.05.2010 06:55, Andrew Sutherland wrote:
<br>
<blockquote type="cite">I would suggest that we do not keep the
'good' revision in revision control, but do publish it at a
public URL and that we do point client.py at it so that random
people who want to build Thunderbird do not need to deal with
breakage.
<br>
</blockquote>
<br>
Nice idea, but I think it is better to commit to repo somehow.
Maybe at slower intervals.<br>
</blockquote>
<br>
Actually, let me refine that. My proposal earlier was:<br>
We commit the *first* (not the last known) revision of m-c that this
version of c-c works with, let me call it "GECKO_VERSION_MIN". In
other words, whenever we make a m-c bustage/compatibility fix, we
also change the "known good" m-c revision. All subsequent checkouts
and revisions of c-c then take that this m-c version. Newer versions
of m-c can be used on your own risk (that is what tinderbox-canary
would track). But you'll always have a good, compatible version of
m-c matching this version of c-c.<br>
<br>
You could also add a second version "also known to work with", let's
say "GECKO_VERSION_GOOD", which is updated in the repo every week or
so, and published on a webserver (SSL, please!). That's the version
you talked about.<br>
<br>
Please put these revision number in a separate file, let's say
build/gecko-version.txt. All that together would give you a range of
versions of m-c that a given c-c works with: anything between
GECKO_VERSION_MIN and GECKO_VERSION_GOOD is sure to be fine.<br>
<br>
(If you're looking at an old revision of c-c, you can also look at
the following revisions of build/gecko-version.txt. The next change
of GECKO_VERSION_MIN *after* the current revision would likely be
the first revision that does not work with this c-c anymore.)<br>
<br>
It's not much work to implement this:<br>
<ul>
<li>whenever you make a m-c bustage or compatibility fix, you
update GECKO_VERSION_MIN and GECKO_VERSION_GOOD in
build/gecko-version.txt in the same commit.</li>
<li>the tinderbox-canary builds update GECKO_VERSION_GOOD in
build/gecko-version.txt automatically, at reasonable intervals,
e.g. one a week or every 3 days.</li>
<li>"client.py checkout" is modified to source/read
build/gecko-version.txt, and checks out the GECKO_VERSION_GOOD
revision. It has a commandline flag --mozilla=latest (or
similar) which checks out m-c trunk instead.<br>
(Optionally, other values of --mozilla= could be: "min"
(GECKO_VERSION_MIN), "good" (GECKO_VERSION_GOOD, the default),
"goodweb" (fetches the latest good version from a website, i.e.
asuth' idea.)<br>
</li>
</ul>
<br>
</body>
</html>