How Do Developers Use Migration Guides? A Case Study of Log4j Takahiro Monno
Nara Institute of Science and Technology Ikoma, Nara, Japan [email protected]
Kazumasa Shimari
Wakayama University Wakayama, Wakayama, Japan [email protected]
arXiv:2604.24072v1 [cs.SE] 27 Apr 2026
Kazuma Yamasaki
Kenichi Matsumoto
Nara Institute of Science and Technology Ikoma, Nara, Japan [email protected]
Abstract Migration guides are a form of software documentation that helps developers address breaking changes introduced in library version updates. Prior studies have examined documents such as release notes, API reference manuals, and patch notes. However, research that focuses specifically on migration guides remains limited. Improving the usability and coverage of migration guides is essential for helping developers resolve breaking changes efficiently. Yet, we still lack a clear understanding of how migration guides are currently provided and how developers use them in practice. To fill this gap, we first investigate whether libraries known to introduce incompatibilities provide migration guides. We then conduct a detailed case study on Log4j, a library that has experienced large-scale breaking updates in the past. We empirically analyze how developers refer to and use the official migration guide in realworld projects. We find that pull request authors most frequently reference the migration guide in the pull request description, and that most references (82.81%) link to the entire guide rather than specific sections. We also find that developers use migration guides not only during major version updates but also during subsequent maintenance tasks, suggesting that the guides serve as a resource throughout the entire migration process.
CCS Concepts • Software and its engineering → Software libraries and repositories; Documentation; Maintaining software.
Keywords Migration Guide, Library Update, Log4j Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. EASE 2026, Glasgow, United Kingdom © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX
Tetsuya Kanda
Notre Dame Seishin University Okayama, Okayama, Japan [email protected]
Nara Institute of Science and Technology Ikoma, Nara, Japan [email protected] ACM Reference Format: Takahiro Monno, Kazumasa Shimari, Tetsuya Kanda, Kazuma Yamasaki, and Kenichi Matsumoto. 2026. How Do Developers Use Migration Guides? A Case Study of Log4j. In Proceedings of The 30th International Conference on Evaluation and Assessment in Software Engineering (EASE 2026). ACM, New York, NY, USA, 6 pages. https://doi.org/XXXXXXX.XXXXXXX
1
Introduction
When library providers release new versions, they sometimes introduce backward-incompatible changes, commonly called “Breaking Changes” [6]. Such breaking changes can render client systems defective or alter their behavior, so developers need to address them whenever they update library versions [18]. Migration guides are documents that summarize the changes between two versions of a library and provide concrete instructions and replacement mappings to help developers update their code [10]. By following migration guides, developers can obtain code-level mappings for resolving breaking changes in their own projects [7, 8]. Prior empirical studies have shown that developers often rely on software documentation and external web resources to understand and recover from breaking changes. For example, Zampetti et al. found that documentation URLs were the second most frequently referenced category of external URLs in GitHub PRs, indicating that developers often share documentation links to support team members during change tasks [21]. Among such documentation, migration guides play an important role because they directly connect old or changed APIs to their new versions and provide clear steps to adapt the code [10]. Despite this practical importance, we still lack a clear understanding of how migration guides are currently provided and how developers use them in practice. Existing studies on documentation that supports library migration have focused on the provider’s perspective, analyzing the content and availability of such documentation. For example, Li et al. reported that migration guides for web service APIs do not always cover all changes introduced in a version update and may even contain omissions and errors [10]. Yasmin et al. examined deprecation practices of RESTful APIs and found that not all providers supply replacement messages directing developers to alternative endpoints [20]. While these findings clarify what providers offer
EASE 2026, Tue 9 - Fri 12 June 2026, Glasgow, United Kingdom
Takahiro Monno, Kazumasa Shimari, Tetsuya Kanda, Kazuma Yamasaki, and Kenichi Matsumoto
to support migration, no empirical study has examined how client developers use migration guides within version update workflows. In this paper, we conduct the first empirical study investigating how developers use migration guides when coping with breaking changes in library dependencies. First, we examine to what extent library providers publish migration guides compared with release notes, thereby quantifying the availability of migration guides. Second, we conduct a case study of Log4j, a widely used logging library that introduced extensive breaking changes between version 1 and version 2, to analyze how developers reference the official migration guide in practice when updating their client software. Together, these empirical analyses provide initial evidence on how migration guides are provided and used in practice. We formulate the following research questions: RQ1: In the development process, who references the migration guide, where in the pull request do they reference it, and at what level of detail? We empirically analyze who refers to migration guides, where the references appear, and the granularity of such references. Unlike prior work that investigates migration guides from the provider side [20], we investigate migration guide usage from the client developers’ perspective. RQ2: For what purposes and in what contexts do developers reference the migration guide? Multiple authors conduct a manual analysis of the PRs examined in RQ1 to deepen our understanding of how migration guides are used. Specifically, we analyze development and maintenance activities in the PRs as well as the status of library updates, and we exploratorily examine developers’ purposes for referring to migration guides. Contributions: • To the best of our knowledge, this study is the first empirical study investigating how migration guides are utilized in OSS. • We find that PR authors most frequently reference the migration guide in the pull request description, and that most references (82.81%) link to the entire guide rather than specific sections. • We also find that developers use migration guides not only during major version updates but also during subsequent maintenance tasks, suggesting that the guides serve as a resource throughout the entire migration process. Replication Package: To facilitate replication and further studies, we provide the data and source code used in our study as a replication package on Zenodo1 .
2 Related Work 2.1 Importance of Migration Guides Migration guides are indispensable for coping with breaking changes, a routine yet burdensome part of library evolution. In Java libraries, breaking changes are not exceptional: about 30% of API changes introduce backward incompatibility [19]. Moreover, dependency updates often lag [11]; 32% of developers avoid updating due to compatibility concerns [3], and many projects took several months to adopt patched Log4j versions after critical vulnerabilities were disclosed [17]. This lag makes breaking changes particularly costly 1 https://doi.org/10.5281/zenodo.18845533
to handle, and prior research [10] shows that, by following migration guides, developers can obtain code-level mappings that help them resolve breaking changes effectively. Accordingly, migration guides play a crucial role in supporting developers during version updates. Therefore, migration guides provide an important means to support developers when they face breaking changes.
2.2
Existing Studies on Migration Guides
Existing work has examined migration guides and software documentation from several angles. Li et al. reported that official migration guides for web service APIs do not always cover all changes introduced in a version update and may even contain omissions and errors, indicating that migration guides are not always complete or accurate [10]. For example, in Sina Weibo API, they found an omission and a mistake in the migration guide. Ko et al. analyzed 260 API documents for deprecated Java APIs and found that 39% of them did not provide information about alternative APIs, suggesting that important migration-related elements are often missing and may hinder users’ update tasks [8]. Brito et al. further showed that, when coping with difficult breaking changes, library users frequently turn to community Q&A sites to search for concrete solutions, especially when official documentation is insufficient [1]. These existing works collectively suggest that official documentation often fails to provide sufficient guidance for migration tasks. However, they either analyze software documentation broadly without isolating migration-specific guides or focus on the provision of information from the authors’ side. Our study focuses exclusively on migration guides, which play a crucial role in addressing breaking changes. From the perspective of developers, our study aims to identify key issues in migration guides by analyzing how they are utilized within actual development workflows.
3 Preliminary Study 3.1 Purpose This preliminary study investigates the current landscape of documentation supporting library version updates. Prior studies [20] have reported the limited availability of migration guides for deprecated APIs. In preparation for our empirical investigation into migration guide usage, we conducted a preliminary survey to verify the scarcity of such guides. In this study, we focused on migration guides and release notes as the primary sources of documentation containing information regarding library updates.
3.2
Method
We analyzed a dataset of breaking change instances that prior research collected [14]. The dataset includes 571 instances of breaking changes from 153 Java projects. We conducted the analysis as follows. First, we extracted all libraries that introduced breaking changes from the dataset. We then examined the GitHub repositories and official websites of each library to confirm whether they provide migration guides or release notes. In this study, we define migration guides as documentation that provides version update information separately from release notes. For libraries that belong to the same framework, such as “spring-core” and “spring-context”, we treated them as a single library group in this study.
How Do Developers Use Migration Guides? A Case Study of Log4j
Table 1: Number of Libraries Providing Migration Guides and Release Notes
Migration Guide Provided Not Provided
3.3
Release Notes Provided Not Provided 28 0 65 8
Result and Implications
Table 1 shows the number of libraries that provide migration guides. Among 101 distinct libraries, 28 provide both migration guides and release notes. In contrast, 65 provide release notes but do not provide migration guides. 8 provide neither migration guides nor release notes. No library provides guides without release notes. These results show that 92.08% of libraries that introduce breaking changes provide release notes. However, only 27.72% provide migration guides. This finding suggests that libraries provide migration guides less frequently than release notes even when they introduce breaking changes, indicating that the current provision of migration guides remains insufficient. The environment that supports library users in handling breaking changes has not yet reached a sufficient level.
4
Study Design
The objective of this study is to clarify how developers use migration guides in real-world projects. In the preliminary survey described in the previous section, we found that many libraries that introduce breaking changes do not provide migration guides. However, for libraries that do provide migration guides, we still do not understand how developers actually use them in practice. In this section, we design a case study to analyze how developers use a migration guide in practice. We focus on Log4j, which provides a migration guide and is widely known for large breaking changes between version 1 and version 2. We conduct an empirical analysis of how developers refer to and use its migration guide.
4.1
Five Perspectives on Migration Guide Usage
We analyze migration guide usage from the following five perspectives in order to understand actual usage patterns. (1) Actor of reference (PR author vs. reviewer) (2) Location of reference (PR description vs. comment) (3) Level of reference (entire guide vs. specific section) (4) Type of development and maintenance activity (5) Library update status (major update vs. no update) Regarding (1) and (2), prior work emphasizes that we need to examine the role of developers and the context in which they work when they require information from external resources [13]. Regarding (3), we examine whether developers use fragment identifiers when they share links to the migration guide. A fragment identifier moves the reader directly to a specific section of a web page. Prior research reports that programmers often avoid careful reading of documents because they struggle to locate the needed information [12]. For (4), we introduce the type of development and maintenance activity as an analytical dimension to organize
EASE 2026, Tue 9 - Fri 12 June 2026, Glasgow, United Kingdom
migration guide usage. Research on software maintenance treats the classification and motivation of change activities as important units of analysis [9]. By distinguishing the types of changes, we aim to clarify the differences in practical support needs. These perspectives assume that developers use migration guides for different purposes depending on the situation. Understanding these patterns is essential for designing guides that support diverse usage scenarios. Based on these perspectives, we conduct an exploratory investigation of migration guide usage.
4.2
Data Collection
We use the following two URLs as links to the Log4j migration guide in our study: the migration guide for the major upgrade 2 and its redirected page 3 . We collect data by using the GitHub Search API to retrieve PRs that reference the migration guide URLs. We then manually filter the collected PRs and retain only those that appropriately reference the URLs. We exclude issues from our analysis and focus only on PRs. Some issues may also be related to library migration, but they do not always result in a certain implementation because issues are often used for raising problems or discussing future plans. In contrast, PRs contain code changes, and we can easily see how the discussion in the PRs is related to the code base. At this initial stage of our investigation into migration guide usage, we consider PRs to be an appropriate unit of analysis.
4.3
RQ1: Quantitative Analysis of Reference Patterns
To investigate how developers use the migration guide in PRs, we define the following dimensions. (1) Actor of reference: We identify whether the user who references the migration guide is the PR author or a reviewer. We also identify whether the actor is a human or a bot. When a PR author references the guide, this action may indicate that the author uses the guide to understand specific migration steps required for implementation. When a reviewer references the guide, this action may indicate that the reviewer uses the guide to verify the correctness of changes or to suggest alternatives. When a bot references the guide, this action may indicate that the guide supports automated version updates. By focusing on the actor, we clarify differences in usage patterns and information needs among different client types. (2) Location of reference: We examine whether the link appears in the PR description or in subsequent comments. When the link appears in the PR description, the author may use the guide to explain the migration policy. When the link appears in comments, developers may use the guide to provide additional explanations, answer questions, or support review feedback. This distinction allows us to determine whether developers use the guide as explanatory material for the PR or as a resource during discussion. If we observe many comment-based references, this pattern may suggest that developers use the guide for interactive problem solving. (3) Level of reference: We examine whether the referenced URL includes a fragment identifier. A fragment identifier indicates that 2 https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html 3 https://logging.apache.org/log4j/2.x/manual/migration.html
EASE 2026, Tue 9 - Fri 12 June 2026, Glasgow, United Kingdom
Takahiro Monno, Kazumasa Shimari, Tetsuya Kanda, Kazuma Yamasaki, and Kenichi Matsumoto
the user directly references a specific section. In contrast, the absence of a fragment identifier may indicate a reference to the entire document or exploratory browsing. This analysis allows us to evaluate how specific the required information is and how important document structure is for effective use. We also quantify the demand for direct access to specific information within the guide. Based on these three dimensions, we conduct an empirical analysis of the collected PRs. As supplementary information, we also record the status of each PR (merged / open / closed) and aggregate these data together with the defined dimensions.
4.4
RQ2: Analysis of Usage Patterns
To clarify in what context and for what purpose developers use migration guides during the development process, we conducted a manual analysis with multiple authors. We filtered the PRs collected in RQ1 by following procedure. First, we aim to understand how human developers use migration guides. Therefore, we excluded cases in which a bot referenced the migration guide. Next, since we focus on how developers utilize migration guides for intentional use in discussion or decision making, we excluded PRs in which the link appeared only inside source code. Finally, we excluded PRs in which the link appeared only inside the terminal command output pasted into the PR body or comment. We applied a translation service for PRs written in languages other than English and retained them in the set for analysis. This is because such PRs are not so many, and we aimed to preserve diversity without further reducing the sample size. In this study, two authors independently reviewed each PR. They assigned labels based on two dimensions: the type of development and maintenance activity, and the library update status. When disagreements occurred, a third author reviewed the conflicting cases and the corresponding labels and recommended a final decision. The first two annotators discussed the recommendation and reached full agreement. We describe the two analyzed dimensions below. (4) Type of development and maintenance activity: We identified the purpose of development in each PR based on commit messages and discussion content. To classify development purposes, we adopted the 14 categories used in prior work [21]. These categories are based on IEEE Standard for Software Maintenance [5], the classification proposed by Swanson [16] (Adaptive, Corrective, and Perfective), and the categories defined by Hindle et al. [4], including Feature Addition and Non Functional Changes. The two authors achieved 87.50% agreement with a Cohen’s kappa of 0.74, indicating substantial agreement [15]. (5) Library update status: We examined whether the developer attempted to update the version of Log4j in the PR. If the developer updated the dependency, we further classified the change as a major update or a minor update. When a developer updates a dependency, the migration guide may help resolve errors caused by breaking changes. In contrast, a PR that does not update Log4j may represent a secondary migration triggered by updates to other libraries, or follow-up work after a previous version update. The two authors achieved 90.00% agreement with a Cohen’s kappa of 0.79, indicating substantial agreement [15].
Table 2: Number of Users who Referenced the Migration Guide in PRs
Human Bot
PR Author 38 15
Reviewer 10 1
Table 3: Location of Migration Guide References in PRs Location Body Comment Source Code Total
Number of PRs 39 (60.94%) 21 (32.81%) 4 (6.25%) 64
Table 4: Granularity of Migration Guide References in PRs Granularity Entire Guide Specific Section Total
Number of PRs 53 (82.81%) 11 (17.19%) 64
5 Results 5.1 RQ1: Quantitative Analysis of Usage Status
We collected 64 PRs that reference the Log4j migration guide. These PRs are based on a total of 54 repositories, covering the period from August 2015 to September 2025. Regarding (1) Actor of reference, as shown in Table 2, the most common case was human PR authors (38), followed by bot PR authors (15), human reviewers (10), and a bot reviewer (1). Regarding the (2) Location of reference, 39 PRs cited the guide in the description, 21 cited it in comments, and 4 cited it inside source codes (Table 3). As for (3) Level of reference shown in Table 4, 53 PRs referenced the entire migration guide, while 11 referenced a specific section. Regarding the status of the collected PRs, 48 were merged, 8 were open, and 8 were closed. The most frequently observed pattern is a human PR author referencing the migration guide in the PR Body. In the project shown in Figure 1,4 the author includes the URL of the migration guide, aiming to encourage the reviewer to consult the guide or to avoid repeating detailed explanations. Among the 11 cases that referenced specific sections, frequently referenced sections include “#Log4j2ConfigurationFormat,” which supports configuration file updates, and “#limitations-of-the-log4j-1-x-brid which documents tools that support migration. Comment-based references account for 32.81% of all cases. Among the seven cases that referenced specific sections in comments, two involved reviewers and five involved PR authors. This result suggests that developers use the migration guide for interactive problem solving during discussion.
4 https://github.com/magnusja/java-fs/pull/6
How Do Developers Use Migration Guides? A Case Study of Log4j
EASE 2026, Tue 9 - Fri 12 June 2026, Glasgow, United Kingdom
70.0
Library Compatibility Corrective Maintenance/Fix
10.0
Non-source Code Change
7.5
Feature Addition
5.0
Adaptive Maintenance
2.5
SCS Management
2.5
DISCARDED
2.5
Figure 1: Example PR Body with Migration Guide Reference
0
10
20
30
40
50
60
Percentage of Classified Pull Requests
70
80
Figure 3: Percentage of Classified Pull Requests by Active Category
RQ2 Summary Answering RQ2, most PRs that reference the migration guide aim to address library compatibility (28 cases, 70.00%). Developers reference the guide not only during major version updates (22 cases, 55.00%) but also in PRs that do not update the version (17 cases, 42.50%). These results suggest that the migration guide functions as a resource throughout the entire version migration process.
Figure 2: Example Review Comment with Migration Guide Reference Table 5: Log4j Update Status in PRs Log4j Update Status Major Update Minor Update Non-Update Total
Number of PRs 22 (55.00%) 1 (2.50%) 17 (42.50%) 40
6
6.1 RQ1 Summary Answering RQ1, human PR authors most frequently reference the migration guide in the PR description (38 cases). Most references link to the entire guide (53 cases, 82.81%), while references to specific sections remain limited (11 cases, 17.19%).
5.2
RQ2: Purposes of Migration Guide Uses
After the preliminary filtering for manual analysis, we analyzed 40 PRs. Regarding the (4) Type of development and maintenance activity, the most frequent category was library compatibility, with 28 cases, which accounts for 70.00 % of the total. The next most frequent categories were corrective maintenance and changes outside the source code. Regarding the (5) Library update status, the most frequent case was a major update, with 22 cases, which accounts for 55.00 % of the total (Table 5). In contrast, 17 PRs did not update Log4j, which accounts for 42.50 %. We identified a characteristic example in the “apache/kafka” project 5 . In this project, developers performed a major Log4j update in PR #17373. After that update, they continued to reference specific sections of the migration guide in PRs #18290, #18370, and #19502, demonstrating maintenance activities after the version update (Figure 2). 5 https://github.com/apache/kafka/pull/18290
Discussion
In this section, we discuss the implications of our findings for migration guide authors and tool developers.
Implications for Migration Guide Authors
Our preliminary study shows that only 27.72% of libraries introducing breaking changes provide migration guides. This gap leaves developers without structured support and forces them to rely on release notes, which are not designed to guide migration tasks. Our RQ2 results reveal that 42.50% of PRs that reference the migration guide did not involve a Log4j version update. This finding indicates that developers consult the migration guide not only during the initial migration, but also during subsequent correction and maintenance tasks. Guide authors should therefore structure their guides to clearly separate information needed at update time from information relevant to follow-up tasks. For example, dedicated sections such as “Step-by-step migration checklist” and “Post-migration troubleshooting” would allow developers to navigate the guide more efficiently depending on their current task. Our RQ1 results also show that only 17.19% of references used fragment identifiers pointing to specific sections, suggesting that the current guide structure does not sufficiently support targeted access. Authors should design section headings and anchors with discoverability in mind to enable precise navigation.
6.2
Implications for Tool Developers
Our findings suggest two concrete opportunities for automated tool support. First, the low provision rate of migration guides (27.72%) indicates a need to reduce the documentation burden on library maintainers. Tool developers should build automated generation
EASE 2026, Tue 9 - Fri 12 June 2026, Glasgow, United Kingdom
Takahiro Monno, Kazumasa Shimari, Tetsuya Kanda, Kazuma Yamasaki, and Kenichi Matsumoto
tools that produce structured draft migration guides from API diffs, commit histories, and related sources. Recent work on LLM-based release note generation [2] demonstrates the viability of this direction, and similar approaches could be applied to migration guide drafting. Second, we found that developers often reference the entire guide rather than specific sections. This suggests that tools could help by automatically surfacing the most relevant section of a migration guide given a developer’s current code change context, an IDE plugin or PR bot for example.
7
Threats to Validity
Construct Validity: We define a reference as a case in which the migration guide URL explicitly appears in the PR description or in comments. However, this definition does not capture cases in which developers consult the guide without embedding the URL. It also does not capture cases in which developers refer to unofficial documentation. Therefore, our approach may underestimate the actual usage of the migration guide. Internal Validity: Our analysis is observational, and we do not claim causal relationships. Differences across PRs may be confounded by task type, repository norms, and code complexity. However, RQ1 does not control for task category. In addition, the GitHub Search API does not search the entire index exhaustively, so some PRs may not appear in the search results. Furthermore, we collected PRs that contain only two specific URLs, namely the former migration guide URL and its redirected page. External Validity: Our qualitative analysis focuses only on Log4j. This focus may limit generalization to other libraries or ecosystems. We analyzed 64 PRs that explicitly reference the migration guide. These samples may reflect project specific or community specific practices rather than broadly applicable behavior.
8
Conclusion and Future Work
In this study, we conducted an empirical and exploratory analysis of migration guide usage through GitHub repository mining and manual analysis. Our results show that human PR authors most often reference the migration guide in the PR description, typically linking to the entire guide. The main purpose of these PRs is to address library compatibility; however, developers also reference the migration guide during follow-up correction tasks after the update. These findings suggest that migration guides serve as a useful resource throughout the continuous maintenance process, not only at the point of version migration. We empirically demonstrate both the important role that migration guides play in the software ecosystem and the existing room for improvement in their availability and structure. Looking ahead, two directions are particularly promising. First, automated tools such as LLM-based draft generators that use API diffs and commit histories could reduce the documentation burden. Second, establishing standardized templates that clearly separate update-time and post-migration information would improve both guide quality and developer navigation.
Acknowledgement This research has been supported by KDDI Foundation and JSPS KAKENHI Nos. JP23K28065, JP24K14895 and JP26K21197.
References [1] Aline Brito, Marco Valente, Laerte Xavier, and Andre Hora. 2020. You Broke My Code: Understanding the Motivations for Breaking Changes in APIs. Empirical Softw. Engg. 25 (03 2020), 1458–1492. doi:10.1007/s10664-019-09756-z [2] Farbod Daneshyan, Runzhi He, Jianyu Wu, and Minghui Zhou. 2025. SmartNote: An LLM-Powered, Personalised Release Note Generator That Just Works. Proc. ACM Softw. Eng. 2, FSE, Article FSE075 (June 2025), 24 pages. doi:10.1145/3729345 [3] Erik Derr, Sven Bugiel, Sascha Fahl, Yasemin Acar, and Michael Backes. 2017. Keep me Updated: An Empirical Study of Third-Party Library Updatability on Android. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS ’17). 2187–2200. doi:10.1145/3133956.3134059 [4] Abram Hindle, Daniel German, Michael Godfrey, and Richard Holt. 2009. Automatic Classification of Large Changes into Maintenance Categories. In Proceedings of the 17th International Conference on Program Comprehension (ICPC 2009). 30 – 39. doi:10.1109/ICPC.2009.5090025 [5] IEEE. 1998. IEEE Standard for Software Maintenance. Technical Report IEEE Std 1219-1998. IEEE. [6] Dhanushka Jayasuriya, Samuel Ou, Saakshi Hegde, Valerio Terragni, Jens Dietrich, and Kelly Blincoe. 2024. An extended study of syntactic breaking changes in the wild. Empirical Softw. Engg. 30, 2 (Dec. 2024), 45 pages. doi:10.1007/s10664-02410563-4 [7] Chia Hung Kao, Cheng-Ying Chang, and Hewijin Christine Jiau. 2022. Towards cost-effective API deprecation: A win–win strategy for API developers and API users. Information and Software Technology 142 (2022), 106746. [8] Deokyoon Ko, Kyeongwook Ma, Sooyong Park, Suntae Kim, Dongsun Kim, and Yves Le Traon. 2014. API Document Quality for Resolving Deprecated APIs. In Proceedings of the 2014 21st Asia-Pacific Software Engineering Conference, Vol. 2. 27–30. doi:10.1109/APSEC.2014.87 [9] Sai Pranav Koyyada, Denim Deshmukh Deepika Badampudi, Vida Ahmadi, and Muhammad Usman. 2022. Towards automated open source assessment – An empirical study. arXiv:2212.00087 [cs.SE] https://arxiv.org/abs/2212.00087 [10] Jun Li, Yingfei Xiong, Xuanzhe Liu, and Lu Zhang. 2013. How Does Web Service API Evolution Affect Clients?. In Proceedings of the 2013 IEEE 20th International Conference on Web Services. 300–307. doi:10.1109/ICWS.2013.48 [11] Courtney Miller, Christian Kästner, and Bogdan Vasilescu. 2023. “We Feel Like We’re Winging It:” A Study on Navigating Open-Source Dependency Abandonment. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2023). 1281–1293. doi:10.1145/3611643.3616293 [12] David Novick and Karen Ward. 2006. Why don’t people read the manual? Departmental Papers (CS) (10 2006). doi:10.1145/1166324.1166329 [13] Luca Ponzanelli, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, and Michele Lanza. 2014. Mining StackOverflow to turn the IDE into a selfconfident programming prompter. In Proceedings of the 11th Working Conference on Mining Software Repositories (Hyderabad, India) (MSR 2014). 102–111. doi:10.1145/2597073.2597077 [14] Frank Reyes, Yogya Gamage, Gabriel Skoglund, Benoit Baudry, and Martin Monperrus. 2024. BUMP: A Benchmark of Reproducible Breaking Dependency Updates. In Proceedings of the 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). 159–170. doi:10.1109/SANER60148.2024. 00024 [15] J. Richard Landis and Gary G. Koch. 1977. The measurement of observer agreement for categorical data. Biometrics 33, 1 (1977), 159–174. [16] E. Burton Swanson. 1976. The dimensions of maintenance. In Proceedings of the 2nd International Conference on Software Engineering. https://api.semanticscholar. org/CorpusID:17035728 [17] Hidetake Tanaka, Kazuma Yamasaki, Momoka Hirose, Takashi Nakano, Youmei Fan, Kazumasa Shimari, Raula Gaikovina Kula, and Kenichi Matsumoto. 2025. Mining for Lags in Updating Critical Security Threats: A Case Study of Log4j Library. In Proceedings of the 22nd International Conference on Mining Software Repositories (MSR 2025). 319–323. doi:10.1109/MSR66628.2025.00058 [18] Daniel Venturini, Filipe Roseiro Cogo, Ivanilton Polato, Marco A Gerosa, and Igor Scaliante Wiese. 2023. I depended on you and you broke me: An empirical study of manifesting breaking changes in client packages. ACM Transactions on Software Engineering and Methodology 32, 4 (2023), 1–26. [19] Laerte Xavier, Aline Brito, Andre Hora, and Marco Tulio Valente. 2017. Historical and impact analysis of API breaking changes: A large-scale study. In Proceedings of the 24th International Conference on Software Analysis, Evolution and Reengineering (SANER 2017). IEEE, 138–147. [20] Jerin Yasmin, Yuan Tian, and Jinqiu Yang. 2020. A First Look at the Deprecation of RESTful APIs: An Empirical Study . In Proceedings of the 36th International Conference on Software Maintenance and Evolution (ICSME 2020). 151–161. doi:10. 1109/ICSME46990.2020.00024 [21] Fiorella Zampetti, Luca Ponzanelli, Gabriele Bavota, Andrea Mocci, Massimiliano Di Penta, and Michele Lanza. 2017. How developers document pull requests with external references. In Proceedings of the 25th International Conference on Program Comprehension (ICPC 2017). IEEE, 23–33.