How Often does a Source Code Unit Change within a Release Window?

To form a training set for a source-code change prediction model, e.g., using the association rule mining or machine learning techniques, commits from the source code history are needed. The traceability between releases and commits would facilitate a systematic choice of history in units of the project evolution scale (i.e., commits that constitute a software release). For example, the major release 25.0 in Chrome is mapped to the earliest revision 157687 and latest revision 165096 in the trunk. Using this traceability, an empirical study is reported on the frequency distribution of file changes for different release windows. In Chrome, the majority (50%) of the committed files change only once between a pair of consecutive releases. This trend is reversed after expanding the window size to at least 10. That is, the majority (50%) of the files change multiple times when commits constituting 10 or greater releases are considered. These results suggest that a training set of at least 10 releases is needed to provide a prediction coverage for majority of the files.