I've been working on a long rewrite of a large application where our app version number has been static for months. This makes it challenging to rollout changes when there are multiple features we want to test in isolation because we can't target anything but the app version and it's very easy to override a feature with another push. If we could target the build number working on multiple features in parallel would be much easier.
Hi @ryanlntn,
Thanks for reporting!
I think that you can use --target-binary-version field for achieve your scenario. But then you should change binary version on every new build for tests. Please check this docs for more info: https://docs.microsoft.com/en-us/appcenter/distribution/codepush/cli#target-binary-version-parameter
Please let me know if it was helpful or you have any questions
Hi @ryanlntn,
I'm going to close this issue for now as I haven't heard from you in a while unfortunately.
Please feel free to reopen it if you have any questions.
Thanks,
Alexander
@alexandergoncharov Sorry for the delayed response. From the documentation it appears --target-binary-version only takes android.defaultConfig.versionName for Android and CFBundleShortVersionString for iOS into account when determining the binary version. I find that it's common to work on multiple features for a single version in tandem and therefore in a CI context it would be much more useful to be able to be able to target android.defaultConfig.versionCode and CFBundleVersion for Android and iOS respectively.
I think targeting the CFBundleVersion and android.defaultConfig.versionCode make more sense, because those are the numbers that are used in the stores to check version changes, whilst the CFBundleShortVersionString and the like is something to show the end users
I agree that this would be great. Apple doesn't support pre-release tags in the CFBundleShortVersionString, which prevents people from targeting alpha releases with a pre-release tag in the semver. It would be nice to be able to target both specific android.defaultConfig.versionCode/ CFBundleVersion, or a range of version codes.
@alexandergoncharov - any chance of reopening this? I'm happy to add any other clarification that is needed.
Most helpful comment
I agree that this would be great. Apple doesn't support pre-release tags in the CFBundleShortVersionString, which prevents people from targeting alpha releases with a pre-release tag in the semver. It would be nice to be able to target both specific
android.defaultConfig.versionCode/CFBundleVersion, or a range of version codes.