Change versionCode/versionName when running with --release

[emiloberg]

Hi,

I've been building-beta releasing-building-beta releasing an Android app for a couple of days now. Pretty much every time I build it I forget to update the versionCode and versionName in the AndroidManifest.xml. I get reminded of this then Google's Developer Console rejects my APK because of the versionCode not being larger than the previous version.

An easy way to make a little bit easier for the developers would be to add a prompt for versionCode/versionName in the CLI if the build is run with the --release flag. And let the predefined value be read from the current AndroidManifest.xml. This way the developer will be reminded to update the versionCode/versionName and if s/he doesn't want to it's just an enter stroke away.

If versionCode/versionName is changed then write it back to the AndroidManifest.xml

As tns build could be a part of a larger build script where user input is not possible, a new flag, such as --auto or --quiet, should probably be added as well - skipping the prompt.

[tjvantoll]

Just as an fyi, I’ve also suggested that the Android version code be configured in an app’s package.json under the “nativescript” key. I’m curious what you think about that idea.

[emiloberg]

Sound idea! And let my proposed prompt update the package.json (which is then used to generate the plist/xml)

[sitefinitysteve]

I keep running into this as well, very much need a version to be merged with the build

[PanayotCankov]

We are planning to allow app/App_Resources/iOS/Info.plist and app/App_Resources/Android/AndroidManifest.xml to contain these numbers and easily stay in source control.

Also we think to provide two additional options --bundle-version for iOS that can be used with tns build ios --bundle-version 11.1.1 ... and --version-code for Android to be used with tns build android --version-code 111 during the build these will be set in the Info.plist and AndroidManifest.xml in the platforms folder. This should ease CI.

Does this sound sufficient?
Should these update the Info.plist and AndroidManifest.xml in the app/App_Resources?
Would similar switches be useful for CFBundleShortVersionString and versionName?

[rosen-vladimirov]

I would like to see the value populated in app/App_Resources.... This way I'll have (in source control) valid information which is the latest published version.
In case this version is not passed and console is interactive, I believe we should prompt the user to input the version he wants to use.

[emiloberg]

Sounds like a good start!

Yes the numbers should be bumped and persisted in Info.plist/AndroidManifest.xml. As you always need to bump the numbers before releasing a new version this will be an easy way to keep track of the current version.

And yes, the same for CFBundleShortVersionString/versionName as you need to bump them as well.

[tjvantoll]

I like the App_Resources proposal a whole lot. I prefer configuring these properties in the native file types, and because of that my only concern here is consistency. We already allow you to specific an app id in your package.json under the "nativescript" key, so putting the version number in Info.plist / AndroidManifest.xml seems inconsistent.

Therefore we may want to consider moving app id out of the package.json file, and just let you configure your CFBundleIdentifier and package in the native files instead. I think it’s fine as long as the starting templates spit out some good default values. I’d love to see the other things I lay out in #478 be supported through this approach as well.

Also we think to provide two additional options --bundle-version for iOS that can be used with tns build ios --bundle-version 11.1.1 ... and --version-code for Android to be used with tns build android --version-code 111 during the build these will be set in the Info.plist and AndroidManifest.xml in the platforms folder. This should ease CI.

I’ll just note that I personally don’t have a need for this workflow. I just want to change the version numbers in my Info.plist and AndroidManifest.xml in App_Resources. That being said I’m not opposed to these options being added to the CLI as a nicety.

[sitefinitysteve]

I dont suppose in the package.json we could do like

"version": {
   "ios": "2.0.0",
   "android": "2.2.0",
},

Or if not seperated, they both use the same version number?

"version": "2.1.1",

I personally would not like\find the need to manually set the version on a build with a parameter... sure it saves me time opening xcode to change it, but fundamentally it's the same thing.

[PanayotCankov]

@tjvantoll: I wanted these for automation because I dislike sed in the Jenkins builds but need its packages to be submit-able in App/Play stores (e.g. each build should print different numbers). If I am building manually I'd bump the numbers in app/App_Resources/... like you would.

@sitefinitysteve: We can. We do so for CFBundleIdentifier already. But I am not sure what's the best approach here. For JS devs setting these in package.json would be somewhat more convenient but then we will end with two different places where you can set them. Also it may frustrate native native developers moving to {N}. P. S. The build numbers for iOS and Android diverge extremely fast.

[tjvantoll]

@PanayotCankov Ah gotcha, that makes a lot of sense. No one likes sed 😛

@sitefinitysteve I would argue that it’s not the same because you don’t have to go into Xcode at all. You just need to open up a pre-provided file and increment a value. I personally think we do ourselves a disservice if we try to abstract away iOS and Android too much. Developers are going to do Google searches and find existing iOS/Android guides and advice, and we stand to benefit from that. We can easily allow version to be configured in your package.json, but we can’t realistically extend that to the tens and hundreds of things people will want to configure for their iOS/Android apps, so for consistency’s sake I prefer sticking with the native file types. That’s also why I’d like to see app id moved out as well 😃

[sitefinitysteve]

I have been convinced!... So why bother with the one in package.json at all then i suppose.