1.82 KB, patch
|Details | Diff | Splinter Review|
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
This is to add support for adding incremental build number in Settings app.
Created attachment 8510210 [details] [diff] [review] Bug_1087940-Make-ro.build.version.incremental-available-through.patch
Created attachment 8510321 [details] [review] Make ro.build.version.incremental available through settings This patch should be built together with gecko patch.
This path is to add incremental "Build Number" on Settings app. deviceinfo has been used in gaia-ui-tests and ftu as following: tests/python/gaia-ui-tests/gaiatest/tests/functional/settings/test_settings_device_info.py tests/python/gaia-ui-tests/gaiatest/apps/settings/regions/device_info.py gaia/apps/system/js/ftu_ping.js apps/system/test/unit/ftu_ping_test.js should I add the build_number to test and ftu in this bug or a new bug?
Why do we need that? Note that you are adding strings, and we are way past string freeze so we can't take that on 2.1.
Hi Fabrice, This field is used to specify our SW version and we want to have the SW version visible in the settings, both for our end users and for internal users. Today we only see the Firefox OS version, gecko version and a build identifier which none of these can be set by us. We are aware that it's late for 2.1, thus we are fine with getting it to 2.2(later version). Thanks
Attachment #8510210 - Flags: review?(fabrice) → review+
Attachment #8510371 - Flags: review?(fabrice) → review?(arthur.chen)
Comment on attachment 8510371 [details] [review] https://github.com/mozilla-b2g/gaia/pull/25456 Newly added strings are only required to be added in the english language file. L10n team will work on the other languages.
Comment on attachment 8510371 [details] [review] https://github.com/mozilla-b2g/gaia/pull/25456 It seems that the build number does not always exist. Could you add logic determining the visibility of the item and related unit tests? Thanks.
Running gaia on top of gonk, "ro.build.version.incremental" is always set to $BUILD_NUMBER (in android tree: build/tools/buildinfo.sh), which in turn is set to "eng.$(USER).$(shell date +%Y%m%d.%H%M%S)" (in build/core/version_defaults.mk), if nothing else is provided (we can always set BUILD_NUMBER as environment variable), so the build number should always exists. I will add the patch for unit test. Thanks.
Shawn, regarding comment9, could you provide inputs from the aspect of the build process? Thanks!
build/tools/buildinfo.sh shows "ro.build.version.incremental" is always there. Hence I agree with comment 9 to have a test case for preventing this.
Comment on attachment 8510371 [details] [review] https://github.com/mozilla-b2g/gaia/pull/25456 Thanks Leila and Shawn. The settings part looks good to me. Flagging Zac for reviewing the gaia ui tests.
Comment on attachment 8510371 [details] [review] https://github.com/mozilla-b2g/gaia/pull/25456 r+, thanks, but can you land the Gecko patch before the Gaia patch? As otherwise of course, then the tests will fail until the Gecko patch matches :)
Attachment #8510371 - Flags: review?(zcampbell) → review+
Fabrice, Can you help landing gecko patch before gaia? Thanks.
checkin-needed isn't needed for uplifts. We have separate queries for it.
Assignee: nobody → leila.hadji
Oh nevermind, it was for the Gaia patch. In the future, a bit of context to the request is appreciated :) Master: https://github.com/mozilla-b2g/gaia/commit/8dc75432e27aa532faffc415b16f409e230ea80b
Argh, this bug somehow never got resolved when the Gecko patch landed on mozilla-central. Sorry for the huge delay here :( https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ff62b8fb461b v2.1: https://github.com/mozilla-b2g/gaia/commit/88c44f2243a5ca1683587aca9faf29023974b96c
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
status-b2g-v2.1: --- → fixed
status-b2g-v2.2: --- → fixed
status-b2g-master: --- → unaffected
status-firefox35: --- → wontfix
status-firefox36: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Why are we pushing strings to a branch that has been string frozen for months?
Crap. I guess that means we should backout at least the Gaia patch? Not sure if the Gecko patch is worth keeping in by itself or not.
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #21) > Crap. I guess that means we should backout at least the Gaia patch? Not sure > if the Gecko patch is worth keeping in by itself or not. It's fine to keep it. No one will be harmed ;)
Backed out the Gaia change. Sorry for the churn. v2.1: https://github.com/mozilla-b2g/gaia/commit/9ec3e0ad324105ad74e7489a7644f14ea8eab497
status-b2g-v2.1S: --- → fixed
You need to log in before you can comment on or make changes to this bug.