Skip to main content

Does creating a build from an old commit affect the versions of packages that will come to the project?

Introduction​

This document discusses the effects of taking a build from an old commit on the versions of the packages that will be included in the project. It includes information on directories that are not included in version control and how to manage third-party dependencies in Gradle patch and CocoaPods. For Android builds, Unity is used to obtain builds, and the inclusion of packages depends on whether we have applied Gradle patch or not. If Gradle patch is not applied, the library packages will be included in the source control as aar files. For Gradle patches, the document discusses how to manage dependencies based on the range specified in the Gradle file. When building for iOS, the project is exported from Unity as an Xcode project, and all packages are additionally prepared for Xcode using CocoaPods. Therefore, the document suggests considering the Podfile.lock file for iOS. The document provides recommendations on how to manage dependencies for both Android and iOS platforms, emphasizing the importance of setting the right version for each package to avoid merge conflicts in case multiple developers are working on the project.

Please ve aware that Directories not included in version control in the project:

  • Library cache, which is regenerated with each build and its content changes.
    • All packages included with UPM
    • Dependencies of packages included as assets

Also we are strongly advise that you read SemVer Documentation

For Android​

We take Android builds from within Unity, so this depends on whether we apply a Gradle patch in Unity.

If no Gradle patch is applied, the library packages will be included in the source control as AAR files. Therefore, in retrograde commits, only the desired package versions will be included.

Let's examine the situation for Gradle patches. When a Gradle patch is applied within Unity, the mainTemplate.gradle file is generated, and the dependencies written to this file are resolved according to the format specified in the Gradle Documentation.

These dependencies are first resolved in the order specified under the project.repositories heading in the Gradle file, and then, by default, the dependency is searched for under ~/.gradle/caches/modules-2/files-2.1, which is locally available. If it is not found here, the dependency is pulled from Maven or JCenter and cached locally, and then resolved from there. If a range is specified for a third-party library dependency and it becomes inevitable to take a build from an old commit, the version control system should be managed by developers using two methods.

  1. If a Gradle patch is applied, the developer should set each library in the range specified in the form of [16.0,17) without specifying the range. For example, like 16.0.3. In this case, the developer should take maximum care with each update to ensure that the desired version is obtained from the version control.

  2. By not applying a Gradle patch, including project dependencies as AAR files in the version control system. As this method will also update these AAR files with each update, they must be included in the version control system. This method may cause merge conflicts in projects with multiple developers, so it should always be ensured that the desired version is selected.

For iOS​

The project is exported from Unity as an Xcode project, and all packages are also prepared separately for Xcode using CocoaPods. Therefore, the Podfile.lock file may be the issue to consider for iOS. Otherwise, pods taken with the ~ sign may have different versions for the developer who made the pod and the developer who implemented it. According to the Podfile syntax

For example, the following library will be resolved to take all dependencies larger than or equal to version 5.0.2 but less than 5.1. In other words, if the developer who created the GoogleSignIn library releases a prepatch or prerelease 5.0.2-0, they can take this version.

pod 'GoogleSignIn', '~> 5.0.2'

Therefore, the developer should make sure that the dependency.xml files in the editor files in the project are set correctly according to the Podfile.lock generated by taking an Xcode output locally before each commit.

For example

<iosPods>  
    <iosPod name="FBSDKCoreKit_Basics" version="~> 16.0" />  
    <iosPod name="FBSDKCoreKit" version="~> 16.0" />  
    <iosPod name="FBSDKLoginKit" version="~> 16.0" />  
    <iosPod name="FBSDKShareKit" version="~> 16.0" />  
    <iosPod name="FBSDKGamingServicesKit" version="~> 16.0" />  
</iosPods>

this block should change with below example.

<iosPods>  
    <iosPod name="FBSDKCoreKit_Basics" version="= 16.0" />  
    <iosPod name="FBSDKCoreKit" version="= 16.0" />  
    <iosPod name="FBSDKLoginKit" version="= 16.0" />  
    <iosPod name="FBSDKShareKit" version="= 16.0" />  
    <iosPod name="FBSDKGamingServicesKit" version="= 16.0" />  
</iosPods>

In summary, for iOS, developers should ensure that the dependency.xml files in the editor folder are correctly set based on the Podfile.lock generated by running pod install locally in Xcode.

Some packages can download another package to the project with another dependency. In this case, if you want to also fix the version of this package, you should include it in the xml as follows:

    <iosPod name="KokteylLog" version="= 1.1.1" />

Conclusion​

In conclusion, when rolling back to a previous commit and building the project, the version of the packages included in the build can be affected. To manage this effectively, developers should carefully control the version of the packages included in their project and manage their dependencies based on the platform-specific considerations outlined in this document. By doing so, they can ensure that their builds are reliable and that they can roll back to previous commits with confidence.