This is probably fine for mozilla-release and mozilla-beta, where the versions stay at a static number. On mozilla-esr10, for some reason we named the default 'nightly' version 10.0.4esrpre. During 10.0.3 build 2 (off default), this was *not* bumped back to 10.0.3. I had to bump and re-tag this manually. We should probably bump the version no matter what build number it is.

I don't think this is related to buildNumber. This is the code that does the bumping: http://hg.mozilla.org/build/tools/file/default/scripts/release/tag-release.py#l71 Which is only conditional on bumpFiles, which is grabbed directly from the release config here: http://hg.mozilla.org/build/tools/file/default/scripts/release/tag-release.py#l223

I'll try to figure out the cause.

Based on my reading of the code and logs, it appears that we're getting inside the bumpFiles block, because 'hg diff' is running, and we even have an empty changeset (1cd6cffd2686). Looking further, it looks like bumpFile() isn't doing anything, and I bet that's because ANY_VERSION_REGEX doesn't support esr: https://github.com/mozilla/build-tools/blob/master/lib/python/build/versions.py#L10 >>> re.compile('^%s$' % ANY_VERSION_REGEX).match('10.0.4esrpre') >>> re.compile('^%s$' % ANY_VERSION_REGEX).match('10.0.4esr') >>> re.compile('^%s$' % ANY_VERSION_REGEX).match('10.0.4pre') <_sre.SRE_Match object at 0x7fcaac6a5b58> >>> re.compile('^%s$' % ANY_VERSION_REGEX).match('10.0.4') <_sre.SRE_Match object at 0x7fcaac6a5ab0> I'll try to fix it. We should probably still switch release sanity's complaints about this to a warning, too.