Semantic Versioning Research Articles

Robotont 3-an accessible 3D-printable ROS-supported open-source mobile robot for education and research.

Educational robots offer a platform for training aspiring engineers and building trust in technology that is envisioned to shape how we work and live. In education, accessibility and modularity are significant in the choice of such a technological platform. In order to foster continuous development of the robots as well as to improve student engagement in the design and fabrication process, safe production methods with low accessibility barriers should be chosen. In this paper, we present Robotont 3, an open-source mobile robot that leverages Fused Deposition Modeling (FDM) 3D-printing for manufacturing the chassis and a single dedicated system board that can be ordered from online printed circuit board (PCB) assembly services. To promote accessibility, the project follows open hardware practices, such as design transparency, permissive licensing, accessibility in manufacturing methods, and comprehensive documentation. Semantic Versioning was incorporated to improve maintainability in development. Compared to the earlier versions, Robotont 3 maintains all the technical capabilities, while featuring an improved hardware setup to enhance the ease of fabrication and assembly, and modularity. The improvements increase the accessibility, scalability and flexibility of the platform in an educational setting.

Dependency Update Strategies and Package Characteristics

Managing project dependencies is a key maintenance issue in software development. Developers need to choose an update strategy that allows them to receive important updates and fixes while protecting them from breaking changes. Semantic Versioning was proposed to address this dilemma, but many have opted for more restrictive or permissive alternatives. This empirical study explores the association between package characteristics and the dependency update strategy selected by its dependents to understand how developers select and change their update strategies. We study over 112,000 Node Package Manager (npm) packages and use 19 characteristics to build a prediction model that identifies the common dependency update strategy for each package. Our model achieves a minimum improvement of 72% over the baselines and is much better aligned with community decisions than the npm default strategy. We investigate how different package characteristics can influence the predicted update strategy and find that dependent count, age, and release status to be the highest influencing features. We complement the work with qualitative analyses of 160 packages to investigate the evolution of update strategies. While the common update strategy remains consistent for many packages, certain events such as the release of the 1.0.0 version or breaking changes influence the selected update strategy over time.

How We Developed a Data Exchange Format: Lessons Learned from Camera Trap Data Package (Camtrap DP)

Camera trapping has revolutionized wildlife ecology and conservation by enabling automated data acquisition, leading to the accumulation of massive amounts of camera trap data worldwide (Steenweg et al. 2016, Kays et al. 2020, Delisle et al. 2021). Although management and processing of camera trap-derived big data are becoming increasingly solvable with the help of scalable infrastructures, harmonization and exchange of the data remain limited, hindering its full potential. We therefore developed a new data exchange format, Camera Trap Data Package (Camtrap DP), to facilitate the exchange, harmonization and archiving of camera trap data at local and global scales (Camtrap DP Development Team 2023). Camtrap DP was developed with two guiding principles. It should: allow easy and interoperable data exchange and be developed openly and collaboratively. allow easy and interoperable data exchange and be developed openly and collaboratively. Camtrap DP structures the data in a simple model consisting of three tables (Deployments, Media, and Observations), which supports a wide range of camera deployment designs, classification techniques and analytical use cases. To describe these tables and the accompanying metadata, we adopted the Frictionless Standards, a collection of open specifications developed by the Frictionless Data project (Fowler et al. 2018), which offer a standardized way to describe datasets, data files and tabular data. Doing so, we did not have to reinvent how to express generic properties such as licenses, contributors, file formats, field names, data types, required values, controlled values, and relationships between tables. We expanded upon those to describe the necessary properties related to camera trapping, relying on existing standards such as Darwin Core (Wieczorek et al. 2012), Audiovisual Core (Audiovisual Core Maintenance Group 2023) and Data Cite Metadata Schema (DataCite Metadata Working Group 2021) where possible. This approach is not only efficient, but also facilitates interoperability: since a Camtrap DP is in essence a Frictionless Data Package, existing software tools can be used to read and validate data. We developed Camtrap DP openly, collaboratively, and with version control from the start. It is licensed under the permissive MIT license, allowing anyone to use it. Suggestions for change were and continue to be discussed in a public issue tracker on GitHub. These are incorporated only after review and automated testing. Once a number of changes have been adopted, a new version of the standard is released using semantic versioning. This allows Camtrap DP to evolve over time, while making sure that software and datasets referring to older versions of the standard are still valid. Equally important to the success of a data exchange format is community-wide adoption, which requires trust and implementation by existing systems. From the start, we have involved researchers as well as maintainers of software tools and management platforms from the camera trapping community. Using an iterative approach, they tested and provided feedback on Camtrap DP to make sure it met their requirements. To aid their understanding of the format, we provided a website, an example dataset that is versioned with the format, and an R package to read, explore and visualize Camtrap DP datasets (Oldoni et al. 2023). Through open development and outreach, we also managed to get the support from trusted and well-recognized organizations such as Biodiversity Information Standards (TDWG) and the Global Biodiversity Information Facility (GBIF). As a result, Camtrap DP can now be used as a data publication format in the Integrated Publishing Toolkit (Robertson et al. 2014).

On the relation of method popularity to breaking changes in the Maven ecosystem

Software reuse is a common practice in modern software engineering to save time and energy while accelerating software delivery. Dependency managers like MAVEN offer a large ecosystem of reusable libraries that build the backbone of software reuse. Breaking changes, i.e., when an update to a library introduces incompatible changes that break existing client programs, are troublesome barriers to this library reuse. Semantic Versioning has been proposed as a practice to make it easier for the users to find safe updates by encoding the change impact in the version number. While this practice is widely studied from the framework perspective, no detailed insights exist yet into the ecosystem perspective. In this work, we study violations of semantic versioning in the MAVEN ecosystem for 13,876 versions of 384 artifacts to better understand the impact these violations have on the 7,190 dependent versioned packages. We found that 67% of the artifacts introduce at least one type of semantic versioning violation, either a breaking change or an illegal API extension in their history. An impact analysis on breaking methods that (direct or transitive) dependents reference, revealed strong centralization: 87% of publicly accessible methods are never used by dependents and among methods with at least one usage, half of the unique calls from dependents concentrate on only 35% of the defined methods. We also studied method popularity and could not find an indication that popularity affects stability: even popular methods break frequently. Overall, we confirm the previous result that Semantic Versioning is violated repeatedly in practice. Our results suggest that the frequency of breaking changes might be a sign of insufficient change-impact awareness on the ecosystem and we believe that developers require more adequate information, like method popularity, to improve their update strategies.

Open or Sneaky? Fast or Slow? Light or Heavy?: Investigating Security Releases of Open Source Packages

Vulnerabilities in open source packages can be a security risk for the downstream client projects. When a new vulnerability is discovered, a package should quickly release a fix in a new version, referred to as a <i>security release</i> in this study. The security release should be well-documented and require minimal migration effort to facilitate fast adoption by the clients. However, to what extent the open source packages follow these recommendations is not known. In this paper, we study (1) the time lag between fix and release; (2) how security fixes are documented in the release notes; (3) code change characteristics (size and semantic versioning) of the release; and (4) the time lag between the release and an advisory publication for security releases over a dataset of 4,377 security advisories across seven package ecosystems. We find that the median security release becomes available within 4 days of the corresponding fix and contains 131 lines of code (LOC) change. However, one-fourth of the releases in our data set still came at least 20 days after the fix was made. Further, we find that 61.5&#x0025; of the security releases come with a release note that documents the corresponding security fix. Still, Snyk and NVD, two popular databases, take a median of 17 days (from the release) to publish a security advisory, possibly resulting in delayed notifications to the client projects. We also find that security releases may contain breaking change(s) as 13.2&#x0025; indicated backward incompatibility through semantic versioning, while 6.4&#x0025; mentioned breaking change(s) in the release notes. Based on our findings, we point out areas for future work, such as private fork for security fixes and standardized practice for announcing security releases.

Back to the Past – Analysing Backporting Practices in Package Dependency Networks

The practice of backporting aims to bring the benefits of a bug or vulnerability fix from a higher to a lower release of a software package. When such a package adheres to semantic versioning, backports can be recognised as new releases in a lower major train. This is particularly useful in case a substantial number of software packages continues to depend on that lower major train. In this article, we study the backporting practices in four popular package distributions, namely <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Cargo</i> , <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">npm</i> , <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">Packagist</i> and <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">RubyGems</i> . We observe that many dependent packages could benefit from backports provided by their dependencies. In particular, we find that a majority of security vulnerabilities affect more than one major train but are only fixed in the highest one, letting thousands of dependent packages exposed to the vulnerability. Despite that, we find that backporting updates is quite infrequent, and mostly practised by long-lived and more active packages for a variety of reasons.

Breaking bad? Semantic versioning and impact of breaking changes in Maven Central

Just like any software, libraries evolve to incorporate new features, bug fixes, security patches, and refactorings. However, when a library evolves, it may break the contract previously established with its clients by introducing Breaking Changes (BCs) in its API. These changes might trigger compile-time, link-time, or run-time errors in client code. As a result, clients may hesitate to upgrade their dependencies, raising security concerns and making future upgrades even more difficult. Understanding how libraries evolve helps client developers to know which changes to expect and where to expect them, and library developers to understand how they might impact their clients. In the most extensive study to date, Raemaekers et al. investigate to what extent developers of Java libraries hosted on the Maven Central Repository (MCR) follow semantic versioning conventions to signal the introduction of BCs and how these changes impact client projects. Their results suggest that BCs are widespread without regard for semantic versioning, with a significant impact on clients. In this paper, we conduct an external and differentiated replication study of their work. We identify and address some limitations of the original protocol and expand the analysis to a new corpus spanning seven more years of the MCR. We also present a novel static analysis tool for Java bytecode, Maracas, which provides us with: (i) the set of all BCs between two versions of a library, and; (ii) the set of locations in client code impacted by individual BCs. Our key findings, derived from the analysis of 119,879 library upgrades and 293,817 clients, contrast with the original study and show that 83.4% of these upgrades do comply with semantic versioning. Furthermore, we observe that the tendency to comply with semantic versioning has significantly increased over time. Finally, we find that most BCs affect code that is not used by any client, and that only 7.9% of all clients are affected by BCs. These findings should help (i) library developers to understand and anticipate the impact of their changes; (ii) library users to estimate library upgrading effort and to pick libraries that are less likely to break, and; (iii) researchers to better understand the dynamics of library-client co-evolution in Java.

A Functional Programming Language with Versions

While modern software development heavily uses versioned packages, programming languages rarely support the concept of versions in their semantics, which makes software updates more bulky and unsafe. This paper proposes a programming language that intrinsically supports versions. The main goals are to design core language features to support multiple versions in one program and establish a proper notion of type safety with those features. The proposed core calculus, called Lambda VL, has versioned values, each containing different values under different versions. We show the construction of the type system as an extension of coeffect calculus by mapping versions to computational resources. The type system guarantees the existence of a valid combination of versions for a program. The calculus enables programming languages to use multiple versions of a package within a program. It will serve as a basis for designing advanced language features like module systems and semantic versioning.

Lost in zero space – An empirical comparison of 0.y.z releases in software package distributions

Distributions of open source software packages dedicated to specific programming languages facilitate software development by allowing software projects to depend on the functionality provided by such reusable packages. The health of a software project can be affected by the maturity of the packages on which it depends. The version numbers of the used package releases provide an indication of their maturity. Packages with a 0.y.z version number are commonly assumed to be under initial development, suggesting that they are likely to be less stable, and depending on them may be considered as less healthy. In this paper, we empirically study, for four open source package distributions (Cargo, npm, Packagist and RubyGems) to which extent 0.y.z package releases and >=1.0.0 package releases behave differently. We quantify the prevalence of 0.y.z releases, we explore how long packages remain in the initial development stage, we compare the update frequency of 0.y.z and >=1.0.0 package releases, we study how often 0.y.z releases are required by other packages, we assess whether semantic versioning is respected for dependencies towards them, and we compare some characteristics of 0.y.z and >=1.0.0 package repositories hosted on GitHub. Among others, we observe that package distributions are more permissive than what semantic versioning dictates for 0.y.z releases, and that many of the 0.y.z releases can actually be regarded as mature packages. As a consequence, the version number does not provide a good indication of the maturity of a package release.

Citation.js: a format-independent, modular bibliography tool for the browser and command line.

BackgroundGiven the vast number of standards and formats for bibliographical data, any program working with bibliographies and citations has to be able to interpret such data. This paper describes the development of Citation.js (https://citation.js.org/), a tool to parse and format according to those standards. The program follows modern guidelines for software in general and JavaScript in specific, such as version control, source code analysis, integration testing and semantic versioning.ResultsThe result is an extensible tool that has already seen adaption in a variety of sources and use cases: as part of a server-side page generator of a publishing platform, as part of a local extensible document generator, and as part of an in-browser converter of extracted references. Use cases range from transforming a list of DOIs or Wikidata identifiers into a BibTeX file on the command line, to displaying RIS references on a webpage with added Altmetric badges to generating ”How to cite this” sections on a blog. The accuracy of conversions is currently 27% for properties and 60% for types on average and a typical initialization takes 120 ms in browsers and 1 s with Node.js on the command line.ConclusionsCitation.js is a library supporting various formats of bibliographic information in a broad selection of use cases and environments. Given the support for plugins, more formats can be added with relative ease.

What Do Package Dependencies Tell Us About Semantic Versioning?

The semantic versioning ( <b xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">semver</b> ) 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 <b xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">semver</b> 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.

Datastorr: a workflow and package for delivering successive versions of 'evolving data' directly into R.

The sharing and re-use of data has become a cornerstone of modern science. Multiple platforms now allow easy publication of datasets. So far, however, platforms for data sharing offer limited functions for distributing and interacting with evolving datasets— those that continue to grow with time as more records are added, errors fixed, and new data structures are created. In this article, we describe a workflow for maintaining and distributing successive versions of an evolving dataset, allowing users to retrieve and load different versions directly into the R platform. Our workflow utilizes tools and platforms used for development and distribution of successive versions of an open source software program, including version control, GitHub, and semantic versioning, and applies these to the analogous process of developing successive versions of an open source dataset. Moreover, we argue that this model allows for individual research groups to achieve a dynamic and versioned model of data delivery at no cost.

Semantic versioning and impact of breaking changes in the Maven repository

Backward-incompatible interface changes are widespread in software libraries.Breaking changes have impact on client systems using these software libraries.Software developers do not follow proposed versioning guidelines. Systems that depend on third-party libraries may have to be updated when updates to these libraries become available in order to benefit from new functionality, security patches, bug fixes, or API improvements. However, often such changes come with changes to the existing interfaces of these libraries, possibly causing rework on the client system. In this paper, we investigate versioning practices in a set of more than 100,000 jar files from Maven Central, spanning over 7 years of history of more than 22,000 different libraries. We investigate to what degree versioning conventions are followed in this repository. Semantic versioning provides strict rules regarding major (breaking changes allowed), minor (no breaking changes allowed), and patch releases (only backward-compatible bug fixes allowed). We find that around one third of all releases introduce at least one breaking change. We perform an empirical study on potential rework caused by breaking changes in library releases and find that breaking changes have a significant impact on client libraries using the changed functionality. We find out that minor releases generally have larger release intervals than major releases. We also investigate the use of deprecation tags and find out that these tags are applied improperly in our dataset.