This presentation accompanies a scientific article published in IEEE Transactions of Software Engineering in May 2019. See https://doi.org/10.1109/TSE.2019.2918315 The research was carried out by the Belgian Excellence of Science research project SECO-ASSIST, financed by F.R.S.-FNRS and FWO-Vlaanderen. See https://secoassist.github.io Abstract of talk: The semantic versioning (semver) policy is commonly accepted by open source package management systems to inform whether new releases of software packages introduce possibly backward incompatible changes. Maintainers depending on such packages can use this information to avoid or reduce the risk of breaking changes in their own packages by specifying version constraints on their dependencies. Depending on the amount of control a package maintainer desires to have over her package dependencies, these constraints can range from very permissive to very restrictive. This article empirically compares semver compliance of four software packaging ecosystems (Cargo, npm, Packagist and Rubygems), and studies how this compliance evolves over time. We explore to what extent ecosystem-specific characteristics or policies influence the degree of compliance. We also propose an evaluation based on the "wisdom of the crowds" principle to help package maintainers decide which type of version constraints they should impose on their dependencies.

1. Tom Mens, Alexandre Decan
Software Engineering Lab
What do package
dependencies tell us about
semantic versioning?
IEEE Transactions on Software Engineering, May 2019
https://doi.org/10.1109/TSE.2019.2918315

2. SECO-ASSIST
"Excellence of Science”
Research Project
2018-2021
secoassist.github.io@secoassist

3. Characterising the evolution of
package dependency networks
Decan & Mens (2019) An Empirical Comparison of Dependency Network Evolution in
Seven Software Packaging Ecosystems. Empirical Software Engineering
830K packages – 5.8M package versions – 20.5M dependencies (April 2017)

4. Observation: Dependency Hell
Package updates may cause many maintainability
issues or even failures in dependent packages.
"Especially with respect to package
dependencies, the risk of things breaking at
some point due to the fact that a version of a
dependency has changed without you
knowing about it is immense. That actually
cost us weeks and months in a couple of
professional projects I was part of."

5. Observation: Outdated dependencies
Many package maintainers do not update the
dependencies of their packages.
> 1 out of 3 dependents never
� update their dependency
A Zerouali et al (Feb. 2019) A formal framework for measuring
technical lag in component repositories – and its application to npm.
Wiley Journal on Software Evolution and Process

6. Should package
maintainers upgrade
their dependencies?
https://chaoss.community
� Upgrades benefit from bug and security fixes
� Upgrading allows to use new features
� Upgrading requires effort
� Upgrading may introduce breaking changes

7. All Dependencies
Outdated Dependencies
Relation between dependency
constraints and outdatedness
Outdatedness is related to the type of dependency constraint being used
Strict constraints represent about 20% of all dependencies,
but about 33% of all outdated dependenciesSuggestion: Rely on semantic versioning
policy to set dependency constraints

8. How to avoid breaking changes?
Semantic Versioning to the rescue
• For package providers: Inform your dependents about
which releases are backwards compatible
• For package consumers: Decide and control which newer
dependency releases are permitted
major minor patch
3 9 2
Breaking
changes
Backwards
compatible
changes
Bug fixes
Semantic Versioning 2.0.0
https://semver.org

9. To which extent do packages follow
semantic versioning?
A comparison of 4 ecosystems
January 2018 dataset from libraries.io:

10. Dependency constraint syntax
across package managers
Different package managers interpret version constraints in different ways
 Constraint normalization
More restrictive than semver
More permissive than semver

11. Should we treat 0.y.z releases differently?
Many packages depend
on 0.y.z package releases
According to Semantic Versioning 2.0.0 Specification
https://semver.org
“Major version zero (0.y.z) is for initial development. Anything MAY change
at any time. The public API SHOULD NOT be considered stable.”
Monthly proportion of required packages for
which at least one client is still relying on a 0.y.z
81%
35%
30%

12. Permissiveness of dependency constraints
across package managers
Pre-1.0.0 constraints are more permissive than semver
Proportion of dependency constraints that are semver-compliant or more permissive

13. Permissiveness of dependency constraints
across package managers
Post-1.0.0 constraints
Proportion of dependency constraints that are
semver-compliant, more permissive , or more restrictive
• >16% of dependency constraints in npm, Packagist
and Rubygems are restrictive, preventing backward compatible
upgrades from being automatically adopted.
• Cargo, npm and Packagist are mostly semver-compliant.
• All considered ecosystems become more compliant over time.

14. Compliance of packages with
semantic versioning
Proportion of required packages “specialized” towards a specific
constraint type for its reverse dependencies
Recommending dependency constraints based on “wisdom of the crowds”

15. Conclusion
• Different package managers have different policies
• RubyGems does not adhere to semantic versioning
• Cargo, Packagist, npm are mostly semver compliant
• Package managers are more permissive than semver for 0.y.z
releases
• Semantic versioning compliance is increasing over time
• The “wisdom of the crowds” principle could help to decide
which type of constraint to use for new dependencies to
existing required packages
What do package dependencies tell us about semantic versioning?
A. Decan, T. Mens. IEEE Transactions on Software Engineering, May 2019
https://doi.org/10.1109/TSE.2019.2918315