373401 - bootstrap should handle releases based on cherry-picked fixes

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect, P3)

Description

[Robert Helmer [:rhelmer]]

For 1.5.0.3 and 2.0.0.3, we decided to use "minibranches" (branching a subset of the tree instead of the whole thing, in this case just the files we were interested in picking up fixes for). Our usual process is to pull a datestamp and apply tags to it, e.g.:
http://lxr.mozilla.org/mozilla/source/tools/release/Bootstrap/Step/Tag.pm

The Mozilla tree is tagged with e.g. FIREFOX_2_0_0_2_RELEASE and FIREFOX_2_0_0_2_RC1. If respins are needed, then individual revisions are force-tagged to FIREFOX_2_0_0_2_RELEASE and the result is tagged as FIREFOX_2_0_0_2_RC2.

I think it'd simplify the problem if we just branch-tagged the tree for _RELEASE tags, merged fixes from e.g. MOZILLA_1_8_BRANCH that we wanted for a release, and tagged the result as _RCn. Bootstrap would just pull the proper _RELEASE branch and apply the tags.

If we don't do that for some reason, then we'll probably want to make Bootstrap support these cases. We could hack it in using branchTag and pullDate (by specifying e.g. today's date and the latest release as the tag), but it'd be better to just support either pullTag or branchTag+pullDate. That'd require the "Bump" logic be rewritten to ignore what the current version numbers are.

This still doesn't solve the problem of cherry-picking fixes; the operator would need to come around and do a "respin" of the above to pick them up.

I think using release branches would make the intent much clearer than doing this second alternative.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

needed for "release automation", hence marking as critical.

Comment 2

[Robert Helmer [:rhelmer]]

We use GECKO_<date>_RELBRANCH now which solves the concerns in this bug, I think.