cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcin Szczepanski (JIRA)" <>
Subject [jira] [Commented] (CB-5590) Asymetry in cordova build updating platform versions (Android/iOS)
Date Mon, 03 Mar 2014 00:05:21 GMT


Marcin Szczepanski commented on CB-5590:

Might not be the right place to comment on this, but seemed the closest issue to what I'm

I notice that in ios_parser.js there's a comment:

// TODO: add a way to update infoPlist['CFBundleVersion'].

I believe CFBundleVersion should be set to the "versionCode" attribute that is used for Android
as it's the equivalent - ie. the build number or similar.

Is there an existing issue for this that I can't find?

> Asymetry in cordova build updating platform versions (Android/iOS)
> ------------------------------------------------------------------
>                 Key: CB-5590
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.1.0
>         Environment: OSX
>            Reporter: Abel Muiño
>            Assignee: Andrew Grieve
>         Attachments: ios_parser.js.patch
> The version attribute from config.xml updates fields with different semantic in Android
vs iOS.
> Both platforms have 2 different version numbers. One acts as the "public" version number
(published on the markets, etc) and the other acts as a "private" build number (changing with
each development iteration)
> The current behavior is:
> * Android: updates the {{android:versionName}} ( [A string value that represents the
release version of the application code, as it should be shown to users|]
> * iOS: updates the {{CFBundleVersion}} instead: ( [represents an iteration (released
or unreleased) of the bundle and can contain a mix of characters and numbers, as in 12E123|])
> So, android updates the visible version, but iOS updates the private one.
> This should be synced… I think it makes sense to have the {{config.xml version}} be
the public one.
> This means update the iOS tooling to fill the {{CFBundleShortVersionString}} instead.
> That way, {{CFBundleVersion}} and {{android:versionCode}} remain "private versions",
maybe using the build number from a continous integration server…

This message was sent by Atlassian JIRA

View raw message