Understanding When to Adopt a Library: A Case Study on ASF Projects

Abstract

Abstract. Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

Lags in the release, adoption, and propagation of npm vulnerability fixes

“…As outlined in Raemaekers et al (2012), Teyton et al (2012), andBogart et al (2016), dependency management includes making cost-benefit decisions related to keeping or updating dependencies on outdated libraries. Additionally, Robbes et al (2012), Hora et al (2015, Sawant et al (2016), Bavota et al (2015), and Ihara et al (2017) showed that updating libraries and their APIs are slow and lagging. Decan et al (2017) showed the comparison of dependency evolution and issue from three different ecosystems.…”

“…3. Studies by Kula et al (2018b), Bavota et al (2015), Bogart et al (2016), and Ihara et al (2017) show that developers are slow to update their vulnerable packages, which is occasionally due to management and process factors.…”

Extraction of Library Update History Using Source Code Reuse Detection

“…Application developers using a library should replace their library copy with a new version, if the copied version of the library included severe problems such as security vulnerabilities. Adopting a new version of a library may seem a simple task, but have many difficulties [5]. Knowledge about a system's past upgrade activity with respect to a library can help maintainers [6].…”

Managing to release early, often and on time in the OpenStack software ecosystem

“…Library projects where new code libraries are developed and client projects where the libraries are reused organize release management in a different way to accomodate their technical dependencies. On that regard, recent results suggest that client projects are quicker to update libraries with a rapid release cycle compared to actual library projects with a longer release cycle [30]. The same study also suggests that client projects are more likely to adopt the latest version of libraries with shorter release cycles.…”

“…As Git tags apply only to a commit and are not branchaware 30 , OpenStack developers encode key release information such as project name, release series, branch and commit hash, within plain YAML 31 text files. Developers produce a large variety of code that is hosted across multiple Git repositories.…”