A formal framework for measuring technical lag in component repositories — and its application to npm

Abstract

Reusable Open Source Software (OSS) components for major programming languages are available in package repositories. Developers rely on package management tools to automate deployments, specifying which package releases satisfy the needs of their applications. However, these specifications may lead to deploying package releases that are outdated, or otherwise undesirable, because they do not include bug fixes, security fixes, or new functionality. In contrast, automatically updating to a more recent release may introduce incompatibility issues.To capture this delicate balance, we formalise a generic model of technical lag, a concept that quantifies to which extent a deployed collection of components is outdated, with respect to the ideal deployment. We operationalise this model for the npm package manager. We empirically analyze the history of package update practices and technical lag for more than 500K packages with about 4M package releases over a seven-year period. We consider both development and runtime dependencies, and study both direct and transitive dependencies. We also analyze the technical lag of external GitHub applications depending on npm packages. We report our findings, suggesting the need for more awareness of, and integrated tool support for, controlling technical lag in software libraries. KEYWORDS empirical analysis, semantic versioning, software repository mining, software reuse, technical lag INTRODUCTIONOver the past years, depending on external software components has become a common software development practice, especially in the free, Open Source community. 1 This practice can lead to a significant gain in productivity, because of the ability to reuse complex functionality, rather than implementing it from scratch. 2 To further facilitate this form of reuse, many online platforms have been created for distributions of operating systems (eg, Linux distributions such as Debian and Ubuntu) and the most prominent programming languages (eg. npm for JavaScript, MavenCentral for Java, RubyGems for Ruby), totaling millions of reusable components.While the availability and abundance of those reusable components facilitate building software, it can also cause problems in maintenance and evolution. For example, a recent version of an application may be outdated, not because of its own code but due to depending on components that were not updated to their latest versions. If this happens, there is a higher risk of having bugs and security issues that may have been already fixed. 3 On the other hand, updating to more recent releases of reusable components is not for free since it might lead to a risk of facing backward incompatible changes. 4To capture how outdated a deployed software package release is w.r.t. the ''ideal'' situation, Gonzalez-Barahona et al 5 introduced the concept of ''technical lag'' as the increasing lag between upstream development and the deployed system if no corrective actions are taken. Its goal is to enable developers to decide on a more informed basis, whether or not t...

What Do Package Dependencies Tell Us About Semantic Versioning?

“…Decan et al [27] measured such technical lag for npm packages and observed that a large number of packages have outdated dependencies, and a large number of dependencies have a technical lag of several months. As a follow-up work, Zerouali et al [28] proposed and validated a formal framework for technical lag measurement.…”

Vuln4Real: A Methodology for Counting Actually Vulnerable Dependencies

“…. our project has been inactive and production has been halted for indefinite time" Zerouali et al [21] proposed a framework to measure the technical lag (i.e., the time and/or number of versions between the last released library version and the actually used dependency) in open source repositories. In their later study, Zerouali et al [22] claimed that the technical lag of third-party components might lead to the presence of vulnerabilities in Docker images.…”

“…Maven libraries are grouped into multi-module projects where each module is released as a separate artifact. According to the Maven naming conventions 21 , within-project dependencies of a multi-module project have the same groupId. Hence, within-project dependencies can be easily identified by comparing their groupIds.…”

“…Since the time difference between recent releases should have a bigger impact on the Last release interval comparing to the time difference between older releases, the typical statistical model that describes such a process is a simple Exponential Smoothing model [33]: where Release time i is the time interval needed to release the i-th version of a library, 0 < α < 1 is the smoothing parameter that shows how fast the influence of previous 21. https://maven.apache.org/guides/mini/ guide-naming-conventions.html 22.…”

Heard it through the Gitvine: an empirical study of tool diffusion across the npm ecosystem

“…Note that to reduce the data collection effort, our dependency graph is static, reflecting the dependencies at the time of data collection. By manually inspecting a small sample of projects, we observed that dependency changes typically occur when new libraries get added, while existing libraries rarely get removed [85]; therefore, our static graph can be considered as an over-approximation of the true dependencies.…”