Updating bitcode version (Xcode version) used to build SDK should result in major version bump, according to SemVer

[p4checo]

Bugfender was recently upgraded to 1.6.5 and apparently was built with Xcode 10.2's new bitcode, which caused RELEASE builds to break on older Xcode's, like:

ld: could not reparse object file in bitcode bundle: 'Invalid bitcode version (Producer: '1001.0.46.3.0_0' Reader: '1000.11.45.5_0')', using libLTO version 'LLVM version 10.0.0, (clang-1000.11.45.5)' for architecture armv7

This is not a major problem, because as reported on other issues (#26, #33) an easy fix is to either disable Bitcode or upgrade Xcode.

However, if Bugfender is following Semantic Versioning (which I think it is or at least should), then I think this qualifies as a breaking change, don't you think? Otherwise, clients wouldn't have their CI break without apparent reason just because the tool was upgraded on a patch/minor version 💥 (which has already happened on other occasions).

Therefore, please consider this issue as a suggestion for future releases, and feel free to close it.

Cheers! 🍻

[jgimenez]

Hi André, thanks for your suggestion. We always build Bugfender with the AppStore version of Xcode, whatever it is. We do not consider the compiler version as part of our API, hence we do not consider it a breaking change.
As a workaround, for now, as you mentioned yourself, disabling bitcode fixes the issue. Also upgrading to the AppStore version of Xcode would.
We'll take your suggestion in consideration, but I'll close the issue right now because there's nothing to be "fixed".

[dineshflock]

Bugfender was recently upgraded to 1.6.5 and apparently was built with Xcode 10.2's new bitcode

@p4checo I have similar issues but not sure which pod is creating problems. How do you find which xcode version was used to build a specific pod?

[p4checo]

hi @dineshflock

Unfortunately I don't know how to obtain that. But you can probably find out the culprit by disabling Bitcode on one pod one at a time, to find out which one breaks your build. I't s a bit cumbersome if you have many pods, but it should work 😄

We are currently using this for disabling Bitcode in Bugfender, if it helps:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|

            # Disable Bitcode in BugfenderSDK, because they always use latest Xcode which can break RELEASE builds:
            # https://github.com/bugfender/BugfenderSDK-iOS/issues/45
            if config.build_settings['PRODUCT_MODULE_NAME'] == 'BugfenderSDK'
                config.build_settings['ENABLE_BITCODE'] = 'NO'
            end
        end
    end
end

Cheers

[RubenVot]

Hi @p4checo,
Are you still using the previous Xcode version?
I would like to understand the reasons to do that so in the future we can take it into account.
Is it because you had no time to upgrade to Swift5? There is any other reason?
Just curious. Thanks :)

[dineshflock]

Unfortunately I don't know how to obtain that. But you can probably find out the culprit by disabling Bitcode on one pod one at a time, to find out which one breaks your build. I't s a bit cumbersome if you have many pods, but it should work 😄

We are currently using this for disabling Bitcode in Bugfender, if it helps:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|

            # Disable Bitcode in BugfenderSDK, because they always use latest Xcode which can break RELEASE builds:
            # https://github.com/bugfender/BugfenderSDK-iOS/issues/45
            if config.build_settings['PRODUCT_MODULE_NAME'] == 'BugfenderSDK'
                config.build_settings['ENABLE_BITCODE'] = 'NO'
            end
        end
    end
end

Cheers

Ah I was looking for a quick command to do so. But anyways thanks.

[macfanatic]

Took me awhile to figure out that this library broke my builds this morning for a pretty small patch release, definitely not a friendly upgrade process.

I am still using Xcode 10.1 on this project, but I wouldn't have expected to lock down to some random version of this library (ie, 1.6.4 works but 1.6.5 requires me to upgrade Xcode to use it).