Presentation by Tom Mens at FOSDEM21 (Free Open Source Developers Meeting, February 2021). Published in Science of Computer Programming, August 2021. https://doi.org/10.1016/j.scico.2021.102656 Abstract: 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.

1. L0st in Zer0 Space
Canwetrust dependingonpackageswithmajorversion0?
secoassist.github.io

2. L0st in Zer0 Space
SoftwareEngineering Lab
Faculty ofSciences
Tom Mens Alexandre Decan
F0SDEM 2021 – Dependency Management DevRoom–February 2020
secoassist.github.io
https://arxiv.org/abs/2101.00836

3. Packagemanagers, dependenciesand releases
FOSDEM2021– L0stinZer0Space
0.3
# packages 35 K 155 K 180 K 1,218 K
# releases 183 K 956 K 1,520 K 9,383 K
# dependencies 796 K 2,396 K 4,727 K 48,695 K
libraries.io 1.6.0 Open Source Repository and Dependency Metadata

4. 1.0.0 2.3.5
4.0.6
12.8.2
1.0.1
7.1.3
1.2.02.0.0
Packagerelease versions
FOSDEM2021– L0stinZer0Space
0.4
1+ space
0.0.1
0.1.0
0.1
0.2.1
0.1.00.21.1
0.5.5
0.1.9
0.12.3
0 space

5. Unstable
Under development
Stable
Mature
Popular
Packagerelease versions
FOSDEM2021– L0stinZer0Space
0.5
1+ space
0 space

6. FOSDEM 2021 – L0st in Zer0 Space
0.6
« not production-ready » ?
axios
version 0.21.1
46 releases
978 commits
257 contributors
~10M weekly downloads
~50K dependent npm packages
Used by ~3.5M GitHub repos
« mature and stable » ?
zerokit-web-sdk
version 4.0.6
5 releases
16 commits
1 contributor
no longer maintained since July 2017
archived on GitHub in June 2018
1+ space
0 space

7. ZeroVer: 0-based Versioning
“Your software's major version should
never exceed the first and most
important number in computing: zero.”
FOSDEM 2021 – L0st in Zer0 Space
0.7
https://0ver.org

8. only 0.y.z
only 0.y.z
only 0.y.z
only 0.y.z
both
both
both
both
only >= 1.0.0
only >= 1.0.0
only >= 1.0.0
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cargo
RubyGems
npm
Packagist
FOSDEM 2021 – L0st in Zer0 Space
0.8
Do packages get stuck inzero space?
Proportion of packages having release in a given version range
A minority of 0.y.z
packages ever crosses
the 1.0.0 barrier.

9. only 0.y.z
only 0.y.z
only 0.y.z
only 0.y.z
both
both
both
both
only >= 1.0.0
only >= 1.0.0
only >= 1.0.0
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cargo
RubyGems
npm
Packagist
FOSDEM 2021 – L0st in Zer0 Space
0.9
Do packages get stuck inzero space?
Proportion of packages having release in a given version range
92.4%
75.8%
42.4%
27.9%
0-based versioning

10. FOSDEM 2021 – L0st in Zer0 Space
0.10
Do packages get stuck inzero space?
For those packages that crossed the 1.0.0 barrier:
• a majority only took a few months
• 1 out of 5 took over 1 year
• In RubyGems, many took >2 years
Duration between first 0.y.z and first ≥1.0.0
release

11. 1.0.0 2.3.5
4.0.6
12.8.2
1.0.1
7.1.3
1.2.02.0.0
Packagereleases and dependencies
FOSDEM 2021 – L0st in Zer0 Space
0.11
1+ space
0.0.1
0.1.0
0.1
0.2.1
0.1.00.21.1
0.5.5
0.1.9
0.12.3
0 space

12. FOSDEM 2021 – Lost in ZeroSpace
0.12
Should one depend on 0.y.z versions?
www.reddit.com/r/rust/comments/7hr6ib/the_meaning
_of_version_100/
Some reasonably mature crates are still at version 0.y.z or depend on
other crates that are at 0.y.z. This is seen as a bad thing and usually
results in a few GitHub issues pushing the authors of those crates to
change the version to 1.0.
[Depending on a 0.y.z version] means that a project cannot be trusted.
It would be unwise for a business-critical application to have a
dependency that is young and prone to significant changes at any
time. It also indicates that the dependency project simply isn’t done
and might not be ready for use.
jeremyckahn.github.io/blog/2013/12/29/the-fear-of- 1-dot-0-0/

13. FOSDEM 2021 – L0st in Zer0 Space
0.13
Should one depend on 0.y.z versions?
As a software developer, you need to depend on an open source package
distributed through some package manager (npm, Maven, Cargo, …)
Would you trust depending on a package with major version 0?
No
6%
Only if there
is no
alternative
19%
Only after
checking
41%
Sure
34%

14. FOSDEM 2021 – L0st in Zer0 Space
0.14
SemanticVersioning
As a software developer, you need to depend on an open source package
distributed through some package manager (npm, Maven, Cargo, …)
Would you trust depending on a package with major version 0?
Semantic versioning 2.0.0 (semver.org)
« Major version zero is for initial development.
Anything may change at any time.
The public API should not be considered stable. »

15. SemanticVersioning
major minor patch
3 9 2
Version number mainly used to signal backwards compatibility
FOSDEM 2021 – L0st in Zer0 Space
0.15
Most
permissive
Most
Restrictive
Dependent packages can use constraints to remain up-to-date

16. FOSDEM 2021 – L0st in Zer0 Space
0.16
SemanticVersioning and Dependency Constraints
More restrictive
than semver
More permissive
than semver
semver
compliant
IEEE TSE 2019: What do package dependencies tell us about semantic versioning?DOI 10.1109/TSE.2019.2918315

17. FOSDEM 2021 – L0st in Zer0 Space
0.17
Packagemanagerpolicies and conventions
The RubyGems team urges gem developers to follow
the semantic versioning standard for their gem’s
versions. The RubyGems library itself does not
enforce a strict versioning policy, but using an
“irrational” policy will only be a disservice to those in
the community who use your gems.
https://guides.rubygems.org/patterns/
Cargo bakes in the concept of Semantic Versioning, so
make sure you follow some basic rules:
Before you reach 1.0.0, anything goes, but if you make
breaking changes, increment the minor version.
https://doc.rust-lang.org/cargo/reference/manifest.html
Many authors treat a 0.x version as if the x were the
major "breaking change" indicator.
https://docs.npmjs.com/cli/v6/using-npm/semver
The ^ operator […] sticks closer to semantic versioning,
and will always allow non-breaking updates.
For pre-1.0 versions it also acts with safety in mind and
treats ^0.3 as ≥0.3.0 <0.4.0.
https://getcomposer.org/doc/articles/versions.md#caret-version-range-

18. FOSDEM 2021 – L0st in Zer0 Space
0.18
Are 0.y.z packages more permissive thansemver?
« Major version zero (0.y.z) is for initial development.
Anything may change at any time.
The public API should not be considered stable. »
proportion of dependency constraints to 0.y.z
packages accepting at most patches or minor releases
Dependents of 0.y.z packages
assume patches to be compatible.
→ More permissive than semver!

19. FOSDEM 2021 – L0st in Zer0 Space
0.19
Packagemanagerpolicies and conventions
Since April 2014, npminit uses 1.0.0 instead
of 0.1.0 as initial version because
“the semver spec is weirdly magical about
0.x.y versions, and we cannot ever hope to
get everyone to believe what the correct
interpretation of 0.x versions are.”
Package version numbers are deduced from git tags.
bundler sets 0.1.0 as initial version of
new packages.
cargoinit sets 0.1.0 as initial version of new
packages.

20. 0.0.0
0.0.0
0.0.0
0.0.0
0.0.1
0.0.1
0.0.1
0.0.1
0.1.0
0.1.0
0.1.0
0.1.0
1.0.0
1.0.0
1.0.0
1.0.0
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Cargo
RubyGems
npm
Packagist
FOSDEM 2021 – L0st in Zer0 Space
0.20
Packagemanagerpolicies and conventions
Proportion of packages created in 2019, by version number.
96.3%
84.9%
44.3%
35.0%
impact of
0.1.0 default

21. FOSDEM 2021 – L0st in Zer0 Space
0.21
How prevalent are 0.y.z releases?
Monthly proportion of 0.y.z releases
0.y.z releases are abundant and active:
Packagist > 2 out of 10
npm > 3 out of 10
Rubygems > 6 out of 10
Cargo > 9 out of 10
The release policies of Cargo and RubyGems should be adapted to incite
package maintainers to move out of the zero version space sooner.

22. FOSDEM 2021 – Lost in ZeroSpace
0.22
Are 0.y.z releases required by other packages?
Distributions of the number of dependent packages
for required 0.y.z and ≥1.0.0 packages.• Many dependent ≥1.0.0 packages
rely on 0.y.z packages.
• Many 0.y.z packages
are required by ≥1.0.0 packages.
• Little practical difference between
#packages depending on
0.y.z and ≥1.0.0 packages:
comparable release frequency,
#dependents, #open issues,
#stars, #forks, …
Maintainers of 0.y.z packages should strive to cross
the 1.0.0 barrier if other ≥1.0.0 packages depend on
them.

23. FOSDEM 2021 – L0st in Zer0 Space
1.0
Conclusions
• Package (semantic) versioning rules are confusing
• Different for 0.y.z and ≥1.0.0 releases
• Different for distinct package managers
• Zero version space does not coincide with initial development
• Little practical difference between use of 0.y.z and ≥1.0.0 releases
• Artificial psychological 1.0.0 barrier
What to do?
• Increase awareness of versioning rules and dependency constraints
• Increase consistency of versioning policy across package managers
• Adopt semver or make deviations from semver more explicit
• Move out of Zero Space as soon as package is production-ready

24. Questions ?