A Study into the Use of Version Locking in Gradle Projects
J.W. Boerop (TU Delft - Electrical Engineering, Mathematics and Computer Science)
Sebastian Proksch – Mentor (TU Delft - Software Engineering)
C.R. Paulsen – Mentor (TU Delft - Software Engineering)
George Iosifidis – Graduation committee member (TU Delft - Networked Systems)
More Info
expand_more
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons.
Abstract
Developers often use dependency managers to make updating dependencies easier. These dependency managers allow permissive declaration strategies to be used which automatically keep dependencies up-to-date. To prevent these automatic updates from breaking projects, developers can use version locking to lock specific versions in place. To investigate how version locking is used we have done research into version locking in projects using Gradle. We found that version locking is not widely adapted, as only 0.34% of our sampled Gradle projects contained a lock file. Our analysis into the use of version ranges in projects using version locking showed that only 29.5% to 44.4% of analyzed projects using version locking, used version ranges. This is surprising as version locking is most effective when using version ranges. Our research into the effect of version locking showed that in 18.2% of the analyzed projects, version locking prevented the build from failing. Looking into the negative effects of version locking, we found that 9.8% of the dependencies are at risk of being a vulnerability, as for these dependencies there are newer versions available which might introduce security patches.