The patches and review happened in Bug 1137898, but "leave open" tickets are irritating so I'm opening this ticket to track landing and fall-out of the Python machinery. (As opposed to the actual version code calculations.)
Try build results seem reasonable: api-9: 20150710135747 from http://firstname.lastname@example.org/try-android-api-9/fennec-42.0a1.en-US.android-arm.txt api-11: 20150710140529 from http://email@example.com/try-android-api-11/fennec-42.0a1.en-US.android-arm.txt x86: 20150710135923 from http://firstname.lastname@example.org/try-android-x86/fennec-42.0a1.en-US.android-i386.txt
Oh, wait, those are all build IDs. Corresponding version codes are: 20150710135747 corresponds to -DANDROID_VERSION_CODE=2015071022 20150710140529 corresponds to -DANDROID_VERSION_CODE=2015071025 20150710135923 corresponds to -DANDROID_VERSION_CODE=2015071025 That last is interesting, but correct: observe that the stamps differ because the api-11 build started later. I don't know how release engineering handles (or fails to handle!) this situation.
url: https://hg.mozilla.org/integration/fx-team/rev/4901982c704f0135260dcafa4a9d33be982e8a56 changeset: 4901982c704f0135260dcafa4a9d33be982e8a56 user: Nick Alexander <email@example.com> date: Tue Jul 07 16:55:48 2015 -0700 description: Bug 1182579 - Pre: Remove unused UA_BUILDID. r=me url: https://hg.mozilla.org/integration/fx-team/rev/bc4d26832c4b52f39aa9fe66ef08186c839c1d19 changeset: bc4d26832c4b52f39aa9fe66ef08186c839c1d19 user: Nick Alexander <firstname.lastname@example.org> date: Wed Jul 08 12:08:31 2015 -0700 description: Bug 1182579 - Pre: Remove unused MIN_CPU_VERSION. r=me We migrated to use MOZ_MIN_CPU_VERSION in moz.build some time back. url: https://hg.mozilla.org/integration/fx-team/rev/4ec4878f071bd8365bf12bae6ca2cb4a0c168f48 changeset: 4ec4878f071bd8365bf12bae6ca2cb4a0c168f48 user: Nick Alexander <email@example.com> date: Wed Jul 08 12:43:06 2015 -0700 description: Bug 1182579 - Compute Android version codes in Python. r=gps I considered three ways to do this: * one, as a Python script executed with $(shell); * two, as a Python script that writes an include file for the preprocessor; * three, as a function exposed to the moz.build sandbox. I rejected two because it's both tied to the preprocessor, and awkward to make handle the dependency on the buildid (in a file) and additional build defines (in config.status). I rejected three because I know of no precedent for this approach, and it hides the dependency on the buildid. One doesn't handle failures in the script gracefully, but neither did the existing approach. This patch is at least testable.
The motivation for this work is to make Bug 1137898 more tractable. That has to land (and be baked) by the end of the year… and the sooner the better. I would like this uplifted as far as we can manage; we're only two weeks into the cycle, so I'm aiming for beta. I want to make sure this refactor is stable in beta and release with the current version code scheme, and I want it to be ready and waiting when I ask for uplift for Bug 1137898. We'll take each uplift step gently, but there actually isn't significant risk here. It even has tests!
Comment on attachment 8633302 [details] [diff] [review] Landed. I am familiar enough with this to know that regressions are usually rare and easy to fix. Moreover, anything which can improve the build of android is a good thing.
Product: Firefox for Android → Firefox Build System
Target Milestone: Firefox 42 → mozilla42
You need to log in before you can comment on or make changes to this bug.