Dependency Management
Lost in Zero Space
Can we trust depending on packages with major version zero?
When developing open source software end-user applications or reusable software packages, developers depend on software packages distributed through package managers such as npm, Packagist, Cargo, RubyGems. In addition to this, empirical evidence has shown that these package managers adhere to a large extent to semantic versioning principles. Packages that are still in major version zero are considered unstable according to semantic versioning, as some developers consider such packages as immature, still being under initial development.
This presentation reports on large-scale empirical evidence on the use of dependencies towards 0.y.z versions in four different software package distributions: Cargo, npm, Packagist and RubyGems. We study to which extent packages get stuck in the zero version space, never crossing the psychological barrier of major version zero. We compare the effect of the policies and practices of package managers on this phenomenon. We do not reveal the results of our findings in this abstract yet, as it would spoil the fun of the presentation.
This empirical study builds further on our earlier work, in which we have studied different kinds of dependency management issues in software package distributions.
The current empirical evolutionary study is based on recent package management metadata of 1.5 million packages, totaling 12 million package releases and 56 million package dependencies. We analyse dependency version constraints to determine:
* to which extent packages depend on 0.y.z releases of other packages;
* whether packages with major version zero ever cross the psychological barrier of 1.0.0;
* whether there is any reluctance to depend on 0.y.z packages;
* whether dependency constraints are more permissive than what semantic versioning dictates for packages in major version zero.
Additional information
| Type | devroom |
|---|
More sessions
| 2/7/21 |
The goal of the EU project FASTEN is being able to perform a more sophisticated analysis of security-vulnerability propagation, licensing compliance, and dependency risk profiles (among others) by relying on the call-level dependency network of the whole software ecosystem. We outline the purpose and structure of the project, and present some preliminary results.
|
| 2/7/21 |
The talk introduces DepClean, an open-source tool that we developed to automatically determine the presence of bloated dependencies in Maven artifacts. DepClean performs a deep static analysis of the dependency network and suggests direct and transitive dependencies to be removed or excluded. Given an application and its build file, DepClean collects the complete dependency tree (the list of dependencies declared in the pom.xml, as well as the transitive dependencies) and analyzes the bytecode ...
|
| 2/7/21 |
Despite best intentions, Open Source releases with regression errors are published every day. In the best case scenario, a downstream user detects it early thanks to good tests, files an issue, and the maintainer can fix it before too many people have upgraded. Other scenarios involve various degrees of brokenness and games of "is it broken for everyone or just me?". Renovate Bot is an open source dependency automation tool but which also is run as a free app on github.com, where it is installed ...
|
| 2/7/21 |
The Solarwinds breach at the end of 2020 is an event that we won't truly understand the breadth and depth of for some time - if ever. But already, several discussions we've been having in the abstract for years have become very concrete. Firstly, the systems we use to develop, code, build and deploy our code are all essential production systems - and should be treated as such. And second, securing the software supply chain is one of the most underrated aspects of security and is often ...
|
| 2/7/21 |
Every software ecosystem seems to have a package manager these days, but reusing software across these ecosystems is still a challenge. Major Linux distributions package software from a wide range of languages, but they restrict the versions you can install, and they make deep assumptions about compilers and runtime libraries to keep everything compatible. If you need a newer libc or a newer Python than the OS offers, you're often on your own. Python packaging supports native libraries, but it ...
|
