Increment at the project instead of the target level.

[lhunath]

It would be great if we could make increment_build_number_in_xcodeproj and increment_version_number_in_xcodeproj modify the CURRENT_PROJECT_VERSION and MARKETING_VERSION values at the project level instead of at an individual target level.

This is especially useful when you are releasing an application that includes multiple targets:

• an application with an extension
• an application with many frameworks

In my scenario, our application currently has 16 framework targets. I do not want to manually specify the exact same version information for all targets - instead I would prefer to define this information at the shared project level and let it be inherited by all project targets.

It is very rare in my opinion that you would actually genuinely want your CURRENT_PROJECT_VERSION to be set at a target-level.

[jdouglas-nz]

Hey @lhunath. That's not a bad idea! I'll have a play with this and see what I can do 👌

[carmelogallo-foodics]

Hi @jdouglas-nz! Any news on this?

[chickdan]

I concur with this request! We have targets for our primary application, Watch, App Clips, Widgets, etc, and currently use the standard increment_version lane but it doesn't sync with the $(MARKETING_VERSION) hence us looking into this plugin. Thank you!

[marcpalmer]

I also expected it to work like this. Having to duplicate the increment_build_number_in_xcodeproj for every target seems crazy, as well as error-prone in case there's ever an issue where one target gets out of sync.

[marcpalmer]

On a quick scan it actually looks like it should be doing this:

fastlane-plugin-versioning/lib/fastlane/plugin/versioning/actions/increment_build_number_in_xcodeproj.rb

Line 33 in feaaff9

def self.set_all_xcodeproj_build_numbers(params, next_build_number)

...but if at first if I didn't pass a target in to the action, I got an error in the Ruby code around a split issue. Seems like my pre-existing project needed the "first time edit of version" somewhere to trigger it to be correct... now I can remove the target: arg from increment_build_number_in_xcodeproj and it is updating them all it seems.

[lhunath]

now I can remove the target: arg from increment_build_number_in_xcodeproj and it is updating them all it seems.

Are you saying that omitting target: is causing the plugin to set each target's individual build number or it's causing the plugin to set the build number at the project level? The goal for this issue is the latter, not the former.

[simon-assistiq]

• Handle version number set at project level #99 implemented this for MARKETING_VERSION but not CURRENT_PROJECT_VERSION I think

It's easy enough to bump the project version using this plugin, but even with only two targets in my project the project file gets changes in like 6 different places, which just means more conflicts to resolve whenever different branches are merged together.