Feature Request: Dependencies.xml should pin to exact versions, not ~> versions

[jmcguirk]

Checklist

• I've updated to the latest released version of the SDK
• I've searched for existing feature requests on GitHub issues
• I've read the Code of Conduct
• I've given my issue the title: Feature Request: [name of my feature request]

Goals

What do you want to achieve?

Currently the FB SDK lists it's own FB dependencies up until a major revision using ~> on pod dependencies and [X.0,Y) versions for gradle dependencies.

While this sort of loose dependency definition is welcome (and desired) for depending on downstream dependencies (such as com.android.support or com.parse.bolts) - I don't think it's appropriate for the actual "first party" libraries that FB is pinning to.

Other large, popular android libraries in this space (IronSource, Firebase, for instance) pin to exact versions for their own libraries.

Earlier today, 11.1.1 was pushed and apparently the actual downstream pom files hadn't finished propagating for the various libraries, and it broke our build.

As a developer, I'd like to be able to validate a known major revision of the FB suite, without having to worry it's changing minor versions under the hood.

Thanks for your consideration!

[murilobast]

Dude, I love you! I was trying to fix my build for hours only to find out that 11.1.1 has been released and it's broken. Fixing it to 11.1.0 solved it

[pashara]

It's not working now. If I set version 11.0.0 inside dependancy file, gradle trying to download file from url like this: https://dl.google.com/dl/android/maven2/com/facebook/android/facebook-share/11.0.0/facebook-share-11.0.0.pom, but here is 404 error.
If version 11.1+, I have same errors:

[jmcguirk]

It's not working now. If I set version 11.0.0 inside dependancy file, gradle trying to download file from url like this: https://dl.google.com/dl/android/maven2/com/facebook/android/facebook-share/11.0.0/facebook-share-11.0.0.pom, but here is 404 error.
If version 11.1+, I have same errors:

Hey Pashara,

What worked for me is pinning them all to 11.1.0 exactly and then running force resolve using External Dependency Manager (potentially necessary depending on how you have EDM configured)

    <androidPackage spec="com.facebook.android:facebook-core:11.1.0" />
    <androidPackage spec="com.facebook.android:facebook-applinks:11.1.0" />
    <androidPackage spec="com.facebook.android:facebook-login:11.1.0" />
    <androidPackage spec="com.facebook.android:facebook-share:11.1.0" />
    <androidPackage spec="com.facebook.android:facebook-gamingservices:11.1.0" />

You should be able to inspect the generated mainTemplate.gradle file is sourcing the pinned versions

implementation 'com.facebook.android:audience-network-sdk:6.5.1' // Assets/IronSource/Editor/ISFacebookAdapterDependencies.xml:8
implementation 'com.facebook.android:facebook-applinks:11.1.0' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:6
implementation 'com.facebook.android:facebook-core:11.1.0' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:5
implementation 'com.facebook.android:facebook-gamingservices:11.1.0' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:9
implementation 'com.facebook.android:facebook-login:11.1.0' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:7
implementation 'com.facebook.android:facebook-share:11.1.0' // Assets/FacebookSDK/Plugins/Editor/Dependencies.xml:8

[ORibn-dev]

I hope they'll fix it soon. I had the same error today with 'com.facebook.android:facebook-share:11.1.1' during Gradle build proccess despite the fact it worked well just few hours ago, dependencies/gradleTemplate are all set for 11.0 version, I didn't touch anything with dependencies for weeks and didn't update Facebook plugin manually, so I was really surprised when it suddenly crashed out of nowhere.

[btmorgan]

Modifying the dependencies file to use explicit versions has been a standard practice of ours for some time now. It is crazy to me that this is not how these files come shipped.

For example, without this modification, it is entirely possible that a scenario like this plays out:

1.) We get QA approval on an internal build to go to Production.
2.) We generate a new production build from the same svn tag that the previously approved internal build was created from.
3.) At some point between 1 and 2, a minor FB update is released.
4.) Despite building from the same tag in our own version control system, the build that was approved for production and the build actually rolled out to production are fundamentally different.

This undermines our own QA efforts and makes our application stability reliant on regression testing of a plugin that has 280+ open issues, many of which never get a response from the engineering team. Here is a prime example of this.