Exact Package version dependencies. Is it a good idea?

[gutley]

Whilst testing out building Firefox with Xcode 4.3 beta, I hit a compiler error in the Kingfisher package:

Now we currently explicitly set the version of Kingfisher to 7.2.2, but the latest version is at 7.6.1. At some point between those two versions the compile error was fixed.

This then led me to question if its really a good idea to require exact package versions or whether it would be better to let them float to up to maybe Next Major version (or at least minor)?

Pros and cons of a fixed version:

Pros

1. Everyone is guaranteed to be using the same version during the build
2. Updates to new versions can be tested as needed

Cons

1. You can soon lag behind the latest minor and bug fix versions unless you manually go looking for them. In the case of Kingfisher we even missed that the minor version of 7.2.x had gone up to 7.2.4. As such known patched bugs in packages will not be picked up.
2. Updating to the latest versions is laborious task as you can't just get Xcode to do it - Each package versions needs be manually modified, both in the project settings themselves and any internal packages (i.e BrowserKit)
3. Out of date packages may also have dependencies on other out of date packages with unpatched bugs etc all the way down.

I am sure the use of exact versions was well considered at the time, but I'm wondering if its time to revisit that.

Also, there is a slight strike against your use of packages when it comes to bringing in some of your own packages. MappaMundi, Fuzi and GCDWebServer are all just tied to master, not explicit Tags, so doing an Update Packages on them just gets the latest. i.e you can't claim Pro (1) as relevant.

Out of curiosity I went and checked how old our in use versions are compared to their latest, including ones where there was a patch release on the same minor version). These are the ones not currently at the latest version.

SwiftProtobuf 1.18.0 (Sep '21) -> 1.20.3 (Nov '22)
KIF 3.8.6 (Dec '21) -> 3.8.7 (Jun '22)
Glean 51.8.3 (Nov '22) -> 52.2.0 (Jan '23)
Adjust 4.29.6 (Sep '21) -> 4.29.7 (Feb '22) -> 4.33.4 ( Feb '23)
Kingfisher 7.2.2 (May '22) -> 7.2.4 (Jun '22) -> 7.6.1 (Feb '23)

In my own fork of Firefox, which also brings in a bunch more packages, I let those extra packages float up to the Next major version, but have a rule to not actually let the update happen until just after an app release - i.e that gives a full release cycle until the next release to spot any anomalies.

[OrlaM]

Hi Gutley, thanks for the feedback. We have created a task to update some of our dependencies that have gotten out of date so should have an update for that soon.

With regards to the policy we use we prefer to use the exact version. The ones that are set to point to master probably should also be versioned but those are managed in house and are very rarely updated so we don’t see it as an issue that needs solving immediately.

This is one of those things where there is no right answer, it’s just a case of which trade offs does the team prefer to live with. On one hand you have stability and confidence when choosing the exact version because you have full control over the timing of when dependencies are updated and you are guaranteed everyone (including any CI builds) are on the same versions. On the other hand you have the convenience of having everything auto update and being confident you have all the latest fixes of the dependencies you use, but the downside that random new issues can seep in unnoticed.

It’s possible in the future as we invest more effort into improving the apps architecture and add a lot more unit and UI testing we will reach a point where we can have enough confidence in our builds to adopt the auto update policy but as things stand today the app has enough random issues that pop up without adding a potential new source of bugs.

[gutley]

@OrlaM - Thanks for the detailed explanation.