Semantic Versioning versus Breaking Changes: A Study of the Maven Repository

Raemaekers, Steven; Deursen, Arie van; Visser, Joost

doi:10.1109/scam.2014.30

Cited by 105 publications

(74 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, previous work by Raemaekers et al (2014) shows that only 50% of the projects on Maven Central use the versioning system in the right way. Due to this, we can not and did not rely on version numbers of the various projects under study to ensure that they are ordered in the right way when we analyze their evolution.…”

Section: Threats To Validitymentioning

confidence: 98%

See 1 more Smart Citation

On the reaction to deprecation of clients of 4 + 1 popular Java APIs and the JDK

2017

View full text Add to dashboard Cite

Application Programming Interfaces (APIs) are a tremendous resource-that is, when they are stable. Several studies have shown that this is unfortunately not the case. Of those, a large-scale study of API changes in the Pharo Smalltalk ecosystem documented several findings about API deprecations and their impact on API clients. We extend this study, by analyzing clients of both popular third-party Java APIs and the JDK API. This results in a dataset consisting of more than 25,000 clients of five popular Java APIs on GitHub, and 60 clients of the JDK API from Maven Central. This work addresses several shortcomings of the previous study, namely: a study of several distinct API clients in a popular, statically-typed language, with more accurate version information. We compare and contrast our findings with the previous study and highlight new ones, particularly on the API client update practices and the startling similarities between reaction behavior in Smalltalk and Java. We make a comparison between reaction behavior for third-party APIs and JDK APIs, given that language APIs are a peculiar case in terms of wide-spread usage, documentation, and support from IDEs. Furthermore, we investigate the connection between reaction patterns of a client and the deprecation policy adopted by the API used.

show abstract

Section: Threats To Validitymentioning

confidence: 98%

“…Java is the most popular programming language according to various rankings (http://www.tiobe.com/tiobe index 2017; http://pypl.github. io 2017), GitHub is the most popular and largest hosting service ) and Maven Central is the largest store of JAR files (Raemaekers et al 2014). (Fig.…”

Section: System Sourcementioning

confidence: 99%

On the reaction to deprecation of clients of 4 + 1 popular Java APIs and the JDK

2017

View full text Add to dashboard Cite

show abstract

“…backward incompatibilities between library versions 3 As noted by Raemaekers [27], these tools are underestimationsas all detected breaking API changes will definitely break an API but some binary compatible APIs could be semantically incompatible.…”

Section: Api Breakage Detection Methodsmentioning

confidence: 99%

“…In recent times, state-of-the-art API breakage detection tools [21,22,23,24,25] have been extensively used by both researchers [26], [27] and practitioners [11], [12] alike, especially for a systematic comparison of API checking Table 2). backward incompatibilities between library versions 3 As noted by Raemaekers [27], these tools are underestimationsas all detected breaking API changes will definitely break an API but some binary compatible APIs could be semantically incompatible.…”

Section: Api Breakage Detection Methodsmentioning

confidence: 99%

An empirical study on the impact of refactoring activities on evolving client-used APIs

Kula

Ouni

Germán

et al. 2018

Information and Software Technology

View full text Add to dashboard Cite

Context: Refactoring is recognized as an effective practice to maintain evolving software systems. For software libraries, we study how library developers refactor their Application Programming Interfaces (APIs), especially when it impacts client users by breaking an API of the library. Objective: Our work aims to understand how clients that use a library API are affected by refactoring activities. We target popular libraries that potentially impact more library client users. Method: We distinguish between library APIs based on their client-usage (refereed to as client-used APIs) in order to understand the extent to which API breakages relate to refactorings. Our tool-based approach allows for a large-scale study across eight libraries (i.e., totaling 183 consecutive versions) with around 900 clients projects. Results: We find that library maintainers are less likely to break client-used API classes. Quantitatively, we find that refactoring activities break less than 37% of all client-used APIs. In a more qualitative analysis, we show two documented cases of where non-refactoring API breaking changes are motivated by other maintenance issues (i.e., bug fix and new features) and involve more complex refactoring operations. Conclusion: Using our automated approach, we find that library developers are less likely to break APIs and tend to break client-used APIs when addressing these maintenance issues.

show abstract

“…This is particularly beneficial as there are several static analysis tools that have now been widely adapted and are part of the standard toolbox used by many developers, such as PMD 1 , Checkstyle 2 , and Findbugs 3 . Recent empirical studies have clearly demonstrated the need for better tools: many developers are not aware of the rules that specify when component evolution is com-patible [14], and empirical studies have demonstrated that this causes issues in realworld systems [16,40].…”

Section: Introductionmentioning

confidence: 99%

API Evolution and Compatibility: A Data Corpus and Tool Evaluation.

Jezek¹,

Dietrich²

2017

JOT

View full text Add to dashboard Cite

The development of software components with independent release cycles is nowadays widely supported by multiple languages and frameworks. A critical feature of any such platform is to safeguard composition by ensuring backward compatibility of substituted components. In recent years, some tooling has been developed to help developers and DevOps engineers to establish whether components are backward compatible by means of static analysis. We investigate the state of the art in this space by benchmarking such tools for Java. For this purpose, we have developed a compact benchmark data set of less than 200KB. Using this dataset, we study possible API changes of Java libraries, and whether the tools investigated can detect them. We find that only a small number of tools suitable to analyse API evolution exist. Those tools are only infrequently maintained by small communities. All tools investigated have some shortcomings in that they fail to detect certain API incompatibilities.

show abstract

Semantic Versioning versus Breaking Changes: A Study of the Maven Repository

Cited by 105 publications

References 17 publications

On the reaction to deprecation of clients of 4 + 1 popular Java APIs and the JDK

On the reaction to deprecation of clients of 4 + 1 popular Java APIs and the JDK

An empirical study on the impact of refactoring activities on evolving client-used APIs

API Evolution and Compatibility: A Data Corpus and Tool Evaluation.

Contact Info

Product

Resources

About