For example, 3.7a4 released under "MozillaDeveloperPreview" branding. The file names of the binaries aren't usual "firefox". The "updates" builder tries to download the previous release using the current product name, so when we decide to release Firefox 4.0 using its usual branding, we should support product renaming (read it from patcher-config?).

Is it only updates that you've seen problems with? (In reply to comment #0) > The "updates" builder tries to download the previous release using the current > product name, This surprises me a bit, based on what's in the patcher config (http://mxr.mozilla.org/mozilla/source/tools/patcher-configs/moz193-branch-patcher2.cfg#67) and in patcher itself (http://mxr.mozilla.org/mozilla/source/tools/patcher/patcher2.pl#330). It ends up downloading the file to "$product-$version.$locale.$platform.complete.mar, though, so the output is probably confusing. > so when we decide to release Firefox 4.0 using its usual > branding, we should support product renaming (read it from patcher-config?). If updates is the only place we're choking because of this, sounds good.

IIRC, it fails while bumping config here: http://hg.mozilla.org/build/tools/file/99c8fb371499/release/patcher-config-bump.pl#l134

Ooooh, that's even easier then. That section should probably be using what's read in from the patcher config, as you suggest. Probably a good time to change that script to use the common version of that function, too: http://hg.mozilla.org/build/tools/file/99c8fb371499/lib/perl/Release/Patcher/Config.pm

Thanks Rail!

Fixed in bug 559057