Closed jdouglas-nz closed 4 years ago
@SiarheiFedartsou Really looking forward to this getting resolved. We have a lot of automated CI tools that read the version number with this plugin that is currently broken after migrating to xcode 11
Thank you @jdouglas-nz !
@jdouglas-nz Hey, thanks for your work! Just one moment: I think we should notice plist_build_setting_support
in README.md, but we can do it in separate PR.
@jdouglas-nz Hey, thanks for your work! Just one moment: I think we should notice
plist_build_setting_support
in README.md, but we can do it in separate PR.
Absolutely. I definitely should call out the new behaviour -- so people know how to use this new functionality 😄
@jdouglas-nz Hey, thanks for your work! Just one moment: I think we should notice
plist_build_setting_support
in README.md, but we can do it in separate PR.Absolutely. I definitely should call out the new behaviour -- so people know how to use this new functionality 😄
Done. please have a read @SiarheiFedartsou
0.4.0 is released 🚀 Big thanks to @jdouglas-nz for it 👍
as a result of xcode 11's new ..opinion.. on where to store the actual values for build number and version number, we need some way to interact with the new storage 'solution' -- the xcodeproj's -- in a fastlane context.
given a lot of people come to this plugin for such an ability - I humbly open this PR.
This PR adds a new flag
plist_build_setting_support
to the existing plist increment actions - with a default value of false - that when set to true, will jump to the new actions - the increment/get build/version from xcodeproj's.Please have a read - and let me know anything you can suggest!
note: I did run a formatter on all the files - and you might notice some differences in formatting (i.e. the array literals of symbols, for example). If you dislike this, please let me know how you've consistently formatted the code and I'll setup my env to do the same