Closed
Bug 622979
Opened 15 years ago
Closed 15 years ago
Update android:versionCode in AndroidManifest.xml in branded builds
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec2.0b4+)
VERIFIED
FIXED
| Tracking | Status | |
|---|---|---|
| fennec | 2.0b4+ | --- |
People
(Reporter: mozilla, Assigned: blassey)
Details
Attachments
(1 file)
|
1.50 KB,
patch
|
dougt
:
review+
|
Details | Diff | Splinter Review |
http://hg.mozilla.org/mozilla-central/file/969691cfe40e/embedding/android/AndroidManifest.xml.in#l6
The versionCode needs to be incremented for us to release a same-version (?) org.mozilla.firefox to the Android Market.
Per IRC around 4.0b3 build 3, Stuart and I prefer to have this actually not be an incremented integer, but some variable (env ANDROIDVERSIONCODE ?) that defaults to buildid if not set. Buildid should take care of ordinary cases; overriding via that variable will allow us to work around any extraordinary cases.
I'm not entirely sure if this needs to be incremented when we're pushing a new version, but it would probably be safest to have this in place before beta 4.
| Reporter | ||
Comment 1•15 years ago
|
||
Also, I'm stating "in branded builds", but it probably won't hurt to set this to buildid in non-branded builds as well.
| Reporter | ||
Updated•15 years ago
|
tracking-fennec: --- → ?
Updated•15 years ago
|
tracking-fennec: ? → 2.0b4+
| Assignee | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> Also, I'm stating "in branded builds", but it probably won't hurt to set this
> to buildid in non-branded builds as well.
I thought so too, bug buildid is too big to be contained in a 32bit unsigned int. I can check in ANDROID_VERSION_CODE which defaults to 1, but the releng scripts will have to increment and set that for each release build. Or we could truncate it to YYYYMMDDHH. Assuming we don't spin more than one release build in an hour that should work, any objections?
| Assignee | ||
Updated•15 years ago
|
Assignee: nobody → blassey.bugs
| Reporter | ||
Comment 3•15 years ago
|
||
I think YYYYMMDDHH will work as a branded default.
| Assignee | ||
Comment 4•15 years ago
|
||
this implements YYYYMMDDHH as a default. It can be over-ridden by setting ANDROID_VERSION_CODE.
Attachment #501347 -
Flags: review?(doug.turner)
Comment 5•15 years ago
|
||
is it better to just have a MOZ_BUILD_DATE exported?
| Assignee | ||
Comment 6•15 years ago
|
||
(In reply to comment #5)
> is it better to just have a MOZ_BUILD_DATE exported?
I don't think it matters, it's only used twice on any given platform
Updated•15 years ago
|
Attachment #501347 -
Flags: review?(doug.turner) → review+
| Assignee | ||
Comment 7•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 8•14 years ago
|
||
Is there a way for us to verify this?
You need to log in
before you can comment on or make changes to this bug.
Description
•