Closest to our work, is the series of work on bug report severity prediction by Menzies and Marcus [16], Lamkanfi et al. [13], [14], and our own previous work [27].
closer to
Closer to our work, in as much as some prediction is being made based on observed rules, are the approaches that use the textual similarity between bug descriptions to assign bugs to developers
Closer XXX
Closer analysis showed that Perl uses a specific semantic versioning approach [27] where even release numbers, like 5.8 and 5.10, are official production releases (with maintenance releases, such as 5.12.1 and 5.12.2 mainly for bug fixes) and odd release numbers, like 5.11 and 5.13, are development releases.
There exists previous work related to build, build failures, and CPAN or other ecosystems.
conducted
Empirical studies of bug characteristics have been conducted in the past to learn about concurrency bugs [27, 33], performance bugs [23, 40], and error handling bugs [13, 16], among many others.
Denny et al. [7] investigated compile errors in short pieces of Java code and how students fixed these errors. They showed that 48% of the builds failed due to compilation errors.
study
Suvorov et al. [9] studied two popular open-source projects, Linux and KDE, and found that the migration from one build system to another might fail due to missing features.
The evolution and maintenance of build system specification files primarily has been studied quantitatively [33, 48, 78].
surveyed
Stahle and Bosch [13] surveyed CI practices and build failures in CI systems.
conduct a study
Vasilescu et al. [15] conducted an empirical study about CI usage on 246 projects from GitHub.
attempt
However, no studies have attempted to study the same phenomena in fault prediction models.
Adams et al. [3], [10] analyzed the changes to the Linux kernel build system and reported that the build system grew and had to frequently be maintained.
McIntosh et al. [11] replicated the same study on the ANT build system. We complement these studies with our predictive model of build failures for the build system of CPAN.
Suvorov et al. [9] studied two popular open-source projects, Linux and KDE, and found that the migration from one build system to another might fail due to missing features.
observe
They observed that test failures during builds are sometimes accepted by developers because developers known that these particular failures will be fixed later [14].
They observed the kind of API changes in the frameworks impacting the clients and classified API changes and API usages.
show
They showed that there exist multiple patterns of build failures and focused on compilation problems to conclude that dependencies are the main source of compilation errors, that the time to fix these errors vary widely, and that developers need more, different tools support.
suggest
The recent study of Gil and Lalouche [9] suggested that code size is the only unique valid metric and therefore fault prediction models should not in fact control for size.
explain
The authors explained that the more a metric is correlated with size, the more able it is to predict bugs.
emphasize
The need to adopt more robust statistical methods in empirical software engineering research has been emphasized recently by Kitchenham et al. [17], as has the (consequent) need to reassess evidence from prior empirical results.
there are problems with
In particular, there are problems with the assumption of normality of data distributions, and also regarding the power and Type I error control of the tests employed in both studies. As such their conclusions may not hold.
Semantic Versioning versus Breaking Changes: A Study of the Maven Repository
To the best of our knowledge, our work is the first systematic study of versioning principles in a large collection of Java libraries. However, several case studies on backward
compatible and incompatible changes in public interfaces as appearing in these libraries have been performed [2], [7], [9]. For instance, Cossette et al. [2] investigate binary
incompatibilities introduced in five different libraries and aim to detect the correct adaptations to upgrade to the newer version of the library. Similarly, Dig et al. [9] investigate binary incompatibilities in five other libraries and conclude that most of the backward incompatible API changes are behavior-preserving refactorings. Dietrich et al. [7] have performed an empirical study into evolution problems caused by library upgrades. They manually detect different kinds of source and binary incompatibilities, and conclude that although incompatibility issues do occur in practice, the selected set of issues does not appear very often.
Another area of active research is to automatically detect refactorings based on changes in public interfaces [3], [4], [8]. The idea behind these approaches is that these refactorings can automatically be “replayed” to update to a newer version of a library. This way, an adaptation layer between the old and the new version of the library can automatically be created, thus shielding the system using that library from backward incompatible changes.
While our work investigates backward incompatibilities for given version string changes, Bauml et al. [1] take the opposite approach, in the sense that they propose a method to generate version number changes based on changes in OSGi
bundles. A comparable approach in the Maven repository would be to create a plugin that automatically determines the correct subsequent version number based on backward incompatibilities and the amount of new functionality present in the new release as compared to the previous one.
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
