Closed Bug 379004 Opened 17 years ago Closed 17 years ago

Categories

(Release Engineering :: General, defect)

x86
All
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cbook, Assigned: nthomas)

References

Details

The Files on http://releases.mozilla.org/pub/mozilla.org/firefox/releases/granparadiso/alpha4/ have still pre as Build ID like Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070426 GranParadiso/3.0a4pre. That means that the first start page is also  a pre Site http://www.mozilla.org/projects/firefox/3.0a4pre/firstrun/.
Assignee: nobody → build
Component: Build Config → Build & Release
Product: Firefox → mozilla.org
QA Contact: build.config → preed
Version: unspecified → other
I've removed the builds from that releases directory.

Looks like I need to move the MOZILLA_1_9a4_RELEASE tag and respin.
Assignee: build → nrthomas
The problem was that MOZILLA_1_9a4_{RC1,RELEASE} tags were applied to the HEAD versions of 
  config/milestone.txt
  browser/config/version.txt
  browser/app/module.ver
rather than the MOZILLA_1_9a4_MINIBRANCH versions.

To fix, I have 
 - pulled from MOZILLA_1_9a4_RELEASE
 - cvs up -r MOZILLA_1_9a4_MINIBRANCH on the three files
 - cvs tag MOZILLA_1_9a4_RC2
 - cvs tag -F MOZILLA_1_9a4_RELEASE on the three files
 - started respins
Blocks: 378905
Fixed by removing builds from ftp and respinning.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
verified with linux and windows build - mac builds are also fine now. 
Status: RESOLVED → VERIFIED
OS: Windows 2000 → All
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.