We definitely could spin a Fennec 1.0.1 under duress, where "spin a 1.0.1" involves many manual steps and human error. We'd very much like to avoid that unless there's a zero-day that forces our hand. I've been describing the blockers in an overview and kept a running list in my head; this bug should track the work in a more specific and shareable way. Some of these may rely on back-porting some mobile-browser changes to the relbranch (if 1.0.1 is spun off the relbranch).
The following are definitely nice-to-haves, not blockers. Noting these in a comment rather than the bug dependency chain. Bug 537426 - clobbering mobile release build directories Bug 543109 - moving candidate build to releases/ Bug 542413 - version bumping. Tempted to put this in the blocker list, but we did get through 1.0 without it. Bug 542579 - separate the multi and en-US builds. This is blocked on separating the two builds in nightlies, but if that happens before 1.0.1 this bug will become a blocker.
(In reply to comment #1) > This is blocked on > separating the two builds in nightlies, but if that happens before 1.0.1 this > bug will become a blocker. This is bug 525327. Bug 537296 - Fennec desktop release builders would be another nice to have.
Adding some blockers that are already resolved, for: - tracking - context - knowing what patches may need to land on relbranch
Per Stuart in IRC, we need to ship Xulrunner with 1.0.1. This means that just writing the automation to work with mobile-browser trunk doesn't work; I need to have it work on the relbranch, which is significantly further behind. And I also have to have it work with trunk for 1.1.
8 years ago