Agile development uses rapid releases to deliver features early and often to users, enabling them to provide quick feedback about the software. We observed that relevant projects, such as Firefox and Chrome, adopt rapid release, but in some cases, the development duration takes longer than the release cycle. This work analyzed whether other projects adopting rapid release also present similar behavior. We analyzed an open-source corpus comprising 1,039 relevant open-source projects, with 13,102 rapid releases and 7,071 traditional releases (without counting the patches), totaling 20,173 releases with 3,167,563 commits. We compared rapid and traditional releases to understand changes regarding the development duration, the development start delay, and the percentage of percentage of commits in the release cycle. We discovered that, in most cases, the development duration of rapid releases is higher than its release cycle, meaning that most projects delivering rapid releases employ parallel release development. However, on average, the amount of work done in parallel has a small impact on the release development. Moreover, the development of rapid releases starts early and without delays. Traditional releases’ development is generally preceded by a pause, probably due to patch development and release stabilization. Therefore, our results suggest that projects that intend to adopt rapid release do not necessarily need to reduce the development duration. The projects may start the release development early and manage parallel release development to achieve a rapid release cycle. This paper was submitted to IEEE Transactions on Software Engineering in October 2023 and is under review.

Database Management Systems (DBMSs) are largely used to store, retrieve, and manage the vast amounts of data that modern applications handle. There are various DBMSs available in the industry. While a few studies have examined the co-evolution of DBMSs and application source code, there is a research gap in examining the adoption of DBMSs in real systems. Knowing the most commonly used DBMSs, how frequently they are used together, and their patterns of replacement can assist project managers in making informed decisions about DBMS adoption. Therefore, we conducted a historical investigation of 317 popular open source end-user applications developed in Java and hosted on GitHub. We determined if these projects had, at any point, employed any of the top 50 DBMSs as ranked by DB-Engines. We observed that MySQL is the most utilized relational DBMS, succeeded by PostgreSQL and H2. Considering only non-relational DBMSs, Redis emerges as the predominant choice, with Cassandra trailing behind. Multi-model DBMSs are top-ranked in Infrastructure Management projects. Furthermore, we found different combinations of subsets of 11 DBMSs being used together at the beginning of the project life cycle (e.g., PostgreSQL and MySQL). Halfway through the project life cycle, we found combinations of 25 DBMSs being used together (e.g., MS SQL Server and Oracle). Finally, at the end of the life cycle, this number increases to 29 DBMSs (e.g., Redis and H2). We also investigated the replacements of DBMSs. We mined sequential patterns and discovered 20 situations where projects replaced DBMSs. For example, we could observe 11 replacements of PostgreSQL in 8 projects in our corpus, with MySQL being a dominant replacement choice, having superseded PostgreSQL in four instances. Conversely, no project switched from MySQL to PostgreSQL. In summary, our study offers insights into the patterns of DBMS adoption, co-use, and replacement tendencies.