patcher-config-bump.pl needs to set prettyVersion again

RESOLVED FIXED

Status

RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: bhearsum, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

During the 3.6rc1 test run that Lukas did we noticed that the patcher config file, and therefore the snippets, end up with 'appv' and 'extv' set to 'appVersion'. Confusingly, we need to set appv to the "version", because that is what AUS uses in the update dialog. To summarize:
extv in the patcher config == 'appVersion' in the release config
appv in the patcher config == 'version' in the release config

We should construct a snippet manually first, to make sure appv does indeed affect the dialog.
Assignee: nobody → bhearsum
Updating the summary.

I need to do some more investigation to make sure this all works, but according to https://bugzilla.mozilla.org/show_bug.cgi?id=498273#c5, we should be able to back out at least some of http://hg.mozilla.org/build/tools/rev/414dcfad8e36. Beltzner would like us to have "pretty" versions in the snippets (eg '3.6 RC 1'), so we would at least need to re-enable the prettyVersion bit. More to come tomorrow.
Summary: patcher-config-bump.pl needs to bump appv to the actual app version → patcher-config-bump.pl needs to set prettyVersion again
Created attachment 414284 [details] [diff] [review]
turn prettyVersion back on

So, I've done a bunch of testing and I *think* this is all we need to do / should do. As part of bug 498273 we disabled both prettyVersion (used as part of appv for beta/betatest) and the <rc> section. To get what we want for the 3.6 RCs we only need to turn prettyVersion back on.

I believe that we can turn the <rc> section back on at this point, which would cause one or two 3.5 betas not to update properly anymore (but who cares), but it's not necessary.

My head is pretty twisted after diving through patcher code, hope the above makes sense.
Attachment #414284 - Flags: review?(nrthomas)
I meant to detail the testing I did:
I set up on staging-stage with a full set of 3.6 snippets and testing the following scenarios:
appv=3.6, 3.6b2 -> 3.6rc1, 3.6b3 -> 3.6rc1
appv=3.6 RC 1, 3.6b2 -> 3.6rc1, 3.6b3 -> 3.6rc1

Both of the 3.6b3 -> 3.6rc1 partial updates worked fine. I tried to test the complete by making the partial MAR a 404, but that resulted in the update hanging at the end of the download of the complete. The complete.txt files worked fine after removing the partial.txt files.

The 3.6b2 -> 3.6rc1 "partial" updates (partial.txt pointing to complete mar) worked fine. Had the same problem with fallback testing and again, removing the partial.txt files got the complete.txt working. Given that this happened for both this an 3.6b3 I think it's caused by a different updater bug, unrelated to this.
No longer blocks: 530112
Comment on attachment 414284 [details] [diff] [review]
turn prettyVersion back on

Sounds like all the bases are covered here for 3.6, and older releases are OK regardless now they're into maintenance mode. r+

You could check with QA on how to failover to the complete update. Something like downloading the partial, exiting, modifying update.status, restart and get complete - you need to put just the right string in the status file. Pretty sure the updater not handling a failed mar download (404 or no response) is already filed.
Attachment #414284 - Flags: review?(nrthomas) → review+
Comment on attachment 414284 [details] [diff] [review]
turn prettyVersion back on

changeset:   427:c9999d50660f
Attachment #414284 - Flags: checked-in+
Should be good to go for RC1 now.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.