get matched pairs by sentence similarity calculation and rank-
ing.
(3) Matched Pairs Analysis. The third step is the subse-
quent analysis of the suggested high-confidence matched pairs.
In Section 2.4, we elaborate on our specific methodologies for
analyzing matched pairs.
2.2. Data Selection and Processing
Due to the huge amount of computation, we need to make
sure we have high-quality input data, which can heavily reduce
unnecessary computational overhead. The data selection, filter-
ing, and processing is to ensure the quality of our data as much
as possible before they are input to RoseMatcher, thus making
our algorithm more efficient.
2.2.1. Selection Criteria of Mobile Apps
As reported in [10], nearly 60% of the mobile apps in app
stores are updated in a non-updating pattern, i.e., the same re-
lease notes are pushed repeatedly. Meanwhile, we observed that
some apps usually release notes in a perfunctory manner with
broad and repetitive statements, rather than specific updating
details. As shown in Figure 3, for example, the release notes of
Facebook and Mcdonald’s are deemed to be low-qualified be-
cause they seldom convey specific or valuable information for
RE researchers. Therefore, we introduced the following four in-
clusion criteria (IC) to select mobile apps with highly qualified
release notes. Note that in this paper, it works as the first-round
selection for the construction of our research dataset.
IC1.1 The app should be released for at least three years.
IC1.2 The release notes of this app should have less than 80%
(suggested) repetition rate after splitting into sentence lev-
els.
IC1.3 The app should have a sufficient amount of release notes
and user reviews.
2.2.2. Data Processing
Our research dataset consists of app release notes and re-
views of the same apps. Generally, the number of user reviews
is much greater than that of the release notes. Meanwhile, app
release notes are often written in a more regular and structured
way. Therefore, our data processing is divided into two parts:
user review processing and release note processing.
Task 1: Data Processing for User Reviews is conducted by
the following three steps.
Step 1.1: Sentence Splitting. One user review usually de-
scribes user feedback from multiple aspects with several sen-
tences. Taking the user review in Figure 4 as an example, it
describes two types of feedback: the first sentence praises the
app, while the second sentence requests a new feature. In or-
der to simplify the analysis of user reviews, NLTK [11] is used
to split the collected user reviews into sentences to ensure each
unit of user reviews only contains one piece of information.
Step 1.2: Sentence pre-processing. In this step, multiple
NLP (Natural Language Processing) techniques were applied to
the textual content of app review sentences. Specifically, NLTK
[11] was adopted to perform stopword removal, punctuation re-
moval, and lemmatization.
Step 1.3: Non-informative review sentences filtering. First,
this paper follows the definition of informative reviews and
non-informative reviews in [7]: ‘informative’ implies that the
review is constructive/helpful to app developers, and “non-
informative” means that the review contains no information that
is useful for improving apps. To remove non-informative re-
views, this paper reused EMNB [12], i.e., the semi-supervised
machine learning algorithm adopted in ARMiner [7], as the
classifier of user reviews.
Compared with supervised algorithms, EMNB fits the case of
a small amount of manually-labeled data along with plenty of
unlabeled data to achieve better performance. Specifically, we
leverage the dataset provided by Chen et al. [7] as the training
data to build the classifier for data filtering.
Task 2: Data Processing for Release Notes, which is con-
ducted by the following two steps.
Step 2.1: Sentence splitting. Similar to user reviews, a re-
lease note usually contains of several release sentences in a list
format. As shown in Figure 1 (a), each piece of information
basically starts a new line with a special symbol (e.g., “−”, “∗”,
or “·”). We observed that some release notes do not end with
a period at the end of each line, which may leads to failure in
sentence-level splitting using the natural language processing
toolkits, like NLTK or SpaCy [13], so we divide the release
notes by paragraphs.
Step 2.2: Duplication removal. This step can be used
to clean duplicated release note sentences from the following
three aspects. First, as mentioned earlier, many apps tend to
make ‘perfunctory’ updates in a pattern that does not deliver
the content of the updating, for example, “Fixed stability is-
sues (Sporify, 2021-11-11)”, “Bug fixes and performance im-
provements (Google Drive, 2020-10-27)”, and “Some bug fixes.
(SHEIN, 2017-11-03)”. These release note sentences occur fre-
quently but seldom bring any details. Therefore, the removal
of this type of release note sentences can greatly increase the
quality of release notes to be included in the research dataset.
Second, some release notes start or end with a welcome or ap-
preciation statement at the beginning or the end of each update,
or for example, “Take collaboration to the next level by connect-
ing over video with Google Meet, part of Google Workspace.
(Google Meet, 2021-08-31)”, and some release notes also tend
to have a general statement before the list of new features, such
as “Some recent additions include: (Pandora, 2019-01-31)”
and “This release brings enhancements that help you get more
out of your inbox: (Gmail, 2018-08-13)”. These release notes
are also often duplicated, and the process can significantly re-
duce their weight in the update log sentences.. Third, release
notes often contain major updates and subsequent minor up-
dates, and a small number of apps repeat the content of major
updates in minor updates for the purpose of reminding users of
their new major features. The de-duplication of keeping only
the initial occurrence of the release notes can ensure the re-
moval of such duplicate information.
3