In the appstore-centric ecosystem, app developers have an urgent requirement to optimize their release strategy to maximize the success opportunity of their apps. To address this problem, we introduce an approach to assisting developers to select the proper release opportunity based on the purpose of the update and current condition of the app. Before that, we propose the interval of an update to its previous update to characterize release patterns, and find significance of the release opportunity through empirical analysis. We mined the update-history data of 17,820 apps from 33 categories in Google Play, over a period of 105 days. With 41,028 releases identified from these apps, we reveal important characteristics of update intervals and how these factors can influence update effects. We suggest developers to synthetically consider app ranking, rating trend, and what to update in addition to the opportunity before releasing an app version. We propose a Multinomial Naive Bayes model to help decide an optimal release opportunity to gain better user adoption.
Despite all the work discussed above on pushing for shorter release cycles, empirical evidence that directly shows its improvements on product quality is lacked. @cite_42 report that bugs are fixed faster under rapid release models, but proportionally less bugs are fixed compared to the traditional release model based on their study of release model of Firefox. @cite_14 found that short release cycles require a more steady flow of releases to control the number of reported bugs. Releasing too frequently not only decreases the time to run tests, but also might make customers weary of yet another update to install ( @cite_36 , @cite_17 ), which is in a way the same situation in app stores.
@cite_36 @cite_14 @cite_42 @cite_17
2088566493 2089472668 2114734045
This paper tells the story of how the team managed to speed up delivery whilst raising quality at the same time, conject used to release complete modules of their Internet platform once every six months. Customers were forced to wait for months to get access to new features. Once they arrived, the big bang releases disrupted the user experience due to bugs lurking in the new software. Despite what seemed to be an impossible task, the team successfully transformed their software development process to deliver a stable and continuous flow of small releases. Now features are delivered to customers more quickly and with much higher quality. Nowadays, many software companies are shifting from the traditional 18-month release cycle to shorter release cycles. For example, Google Chrome and Mozilla Firefox release new versions every 6 weeks. These shorter release cycles reduce the users' waiting time for a new release and offer better marketing opportunities to companies, but it is unclear if the quality of the software product improves as well, since shorter release cycles result in shorter testing periods. In this paper, we empirically study the development process of Mozilla Firefox in 2010 and 2011, a period during which the project transitioned to a shorter release cycle. We compare crash rates, median uptime, and the proportion of post-release bugs of the versions that had a shorter release cycle with those having a traditional release cycle, to assess the relation between release cycle length and the software quality observed by the end user. We found that (1) with shorter release cycles, users do not experience significantly more post-release bugs and (2) bugs are fixed faster, yet (3) users experience these bugs earlier during software execution (the program crashes earlier). The decision for a young product software vendor to release a version of their product is dependent on different factors, such as development decisions (it feels right), sales decisions (the market needs it), and quality decisions (the product is stable). Customers of these products, however, are much more cost oriented when deciding whether to update their product or not, and will look mainly at the cost and value of an update. Product software vendors would gain tremendously if their release package planning method was supported by a similar cost value overview. This paper presents cost value functions for product software vendors to support their release package planning method. These cost value functions are supported by ten misconceptions encountered in seven case studies of product software vendors that these vendors had to adjust during their lifetime. Finally, a number of cost saving opportunities are presented to enable quicker adoption of a release and thus shorten release times and customer feedback cycles.