Closed Bug 662298 Opened 13 years ago Closed 13 years ago

major update automation should be able to be run independently, or as part of the "to" release

Categories

(Release Engineering :: Release Automation: Other, defect, P4)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bhearsum, Unassigned)

Details

When the major update automation was originally designed we were always shipping point releases in sync, which made it quite easy to do them as part of the "from" release. In the new world, we're constantly generating new major updates as part of the "to" release. Eg, 4.0.1 -> 5.0b2, then -> 5.0b3, then -> 5.0b4, etc. Because of the current implementation, we have to muck around with the 4.0.1 release tags to make it work. In addition to it being bad housekeeping, it's rather strange that we need to update the mozilla-2.0 release config as part of every mozilla-beta release. Ideally, I think we should disassociate the major update automation from the rest of it. This could also be a good opportunity to move it to a client side script, and feed it information at runtime.
Component: Release Engineering → Release Engineering: Automation
QA Contact: release → catlee
Bulk move of bugs to Release Automation component.
Component: Release Engineering: Automation (General) → Release Engineering: Automation (Release Automation)
No longer blocks: hg-automation
Mass move of bugs to Release Automation component.
No longer blocks: hg-automation
We're only doing a few more major updates in the forseeable future, and Balrog will obsolete this code.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.