CFBundleVersion set during build

Hello

I’m using custom scripts to generate my plist file, but Corona build keeps on substituting my CFBundleVersion with 1.0.

Please make it so that if there’s no version specified in buildSettings , it will be left alone@ 

It took my a  while to figure out what the hell is going on.

You’re right!  

I set it manually in my Xcode plist, and now I see that every app that’s been submitted to the App Store has had it reset to 1.0!

@CoronaLabs

Please fix.

We’re looking into fixing this.  It’s worked this way for a long time so we want to make sure any fix doesn’t have unexpected side effects.

@Perry,

CFBundleVersion should not be forced to be the same as CFBundleShortVersionString.

I’ve always used CFBundleShortVersionString to denote the version number (string) which is visible to the public, and CFBundleVersion for the internal build number (integer) of the executable. So when looking at a solution please keep this in mind.

I set these explicitly in the Xcode project’s plist and I don’t want the build-scripts to touch them if they exist.

@All

I see this issue has been fixed in build 2014.2415.

Thanks!

It’s fixed for Enterprise but unfortunately doing that broke some other configurations.  We may pull build 2014.2415 until we can fix it for everyone but you are welcome to continue using it if it’s working for you.

Pulling it seems like the thing to do in that case, as Enterprise users can still set these in build.settings I assume…

You’re right!  

I set it manually in my Xcode plist, and now I see that every app that’s been submitted to the App Store has had it reset to 1.0!

@CoronaLabs

Please fix.

We’re looking into fixing this.  It’s worked this way for a long time so we want to make sure any fix doesn’t have unexpected side effects.

@Perry,

CFBundleVersion should not be forced to be the same as CFBundleShortVersionString.

I’ve always used CFBundleShortVersionString to denote the version number (string) which is visible to the public, and CFBundleVersion for the internal build number (integer) of the executable. So when looking at a solution please keep this in mind.

I set these explicitly in the Xcode project’s plist and I don’t want the build-scripts to touch them if they exist.

@All

I see this issue has been fixed in build 2014.2415.

Thanks!

It’s fixed for Enterprise but unfortunately doing that broke some other configurations.  We may pull build 2014.2415 until we can fix it for everyone but you are welcome to continue using it if it’s working for you.

Pulling it seems like the thing to do in that case, as Enterprise users can still set these in build.settings I assume…