社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

メソッドレベルセマンティックバージョニングの提案
林純一†

肥後芳樹†

楠本真二†

† 大阪大学大学院情報科学研究科〒 565-0871 大阪府吹田市山田丘 1-5
E-mail: †{j-hayasi,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし ソフトウェア開発において利用されるライブラリには，機能追加や変更，バグ修正などによる時系列的変化を区別するためのバージョンが付与される．バージョニング手法の 1 つに，セマンティックバージョニングと呼ばれる手法がある．この方法ではライブラリ全体に 1 つのバージョンを付与するため，それだけでは後方互換性がない変更を特定できない．また，先行研究はセマンティックバージョニングの原則に従っていないライブラリがあると指摘している．本研究では，メソッド単位でセマンティックバージョニングを行う手法を提案し，提案手法を用いて Java言語のメソッドにバージョニングを行うツールを作成した．さらに，提案手法および作成したツールの有用性を示すために，提案手法を用いて得たメソッドのバージョンからセマンティックバージョニングに従っていないリリースとその原因となっているメソッドを検出する実験を行った．実験の結果，メソッドに与えたバージョンをもとに後方互換性が失われたメソッドを特定し，誤ったバージョニングが行われたリリースを検出できた．
キーワード メソッドレベルセマンティックバージョニング，バージョン管理システム

1. ま え が き
ソフトウェア開発において利用されるライブラリには，機能の追加や改善あるいはバグや不具合の修正が行われる．このよ的にどの API に後方互換性がないのかということについては別の手段により調べる必要がある．このような手間が発生してしまうこともアップデートへの追従が遅れる要因の 1 つになっていると考えられる．

うな時系列的変化を区別するために「バージョン」が与えられこのような問題を解決するために，本研究ではメソッド単位る．バージョンの表現やそれを決定する方法はライブラリにでバージョンを与える「メソッドレベルセマンティックバー

よって様々であるが，その 1 つとしてセマンティックバージョ

ジョニング (Method-level Semantic Versioning)」という手法

ニング (Semantic Versioning) という，1 つのバージョンを 3を提案する．さらに，Java 言語のソースコードに対して提案手つ組の整数を用いて表す方法が提唱されている [1]．

法を実現するツールを作成し，これらの有用性を確認する実験

セマンティックバージョニングでは公開されている API (Ap-を行った．

plication Programming Interface) に行われた変更に後方互換

先行研究 [2] の調査で用いられた Clirr は入力が JAR (Java性があるかどうかをバージョンに反映させる．しかし，先行研

Archive) ファイルであるため，メソッドの対応付けと後方互換

究 [2] は既存の Java 言語製ライブラリに対して Clirr [3] を用性の判定は JAR ファイルを生成するリリース単位で行われる．

いて調査を行い，セマンティックバージョニングが遵守されて一方，本研究で作成したツールはソースコードが管理されていいないライブラリの存在を指摘している．すなわち，後方互換

る Git リポジトリを入力とし，コミット単位でこれらの処理を性の有無がバージョンに反映されていない可能性がある．さら行う．そのため Clirr よりも細かい間隔でメソッドの対応関係に，ソフトウェアが依存しているライブラリのアップデートへを調べられ，より正確にリリース間のメソッドの対応関係を求の追従が遅延することを指摘している．これは，ソフトウェアめられると考えられる．

開発者がライブラリのバージョンを見ただけでは後方互換性の本稿の構成は以下のとおりである．2 章ではセマンティック有無を正確に判断できず，アップデートの適用に伴う修正作業

バージョニングの定義と問題点について述べる．3 章ではメの必要性や影響範囲を見積もるのに時間を要するためであるとソッドレベルセマンティックバージョニングを提案する．4 章

著者らは考える．

では提案手法を Java 言語のメソッドに適用するツールについまた，セマンティックバージョニングを遵守している場合でて述べる．5 章では提案手法およびツールの有用性を評価するも別の問題が考えられる．後方互換性がない変更が行われた実験について述べる．6 章では実験結果の考察を行う．7 章でAPI が 1 つだけであったとしても，ライブラリのバージョンはは妥当性の脅威について述べる．最後に 8 章で本研究をまと後方互換性がないことを意味するものになる．そのため，具体め，今後の課題について述べる．

—1—後方互換性がある
メソッドを含む

2. セマンティックバージョニング
2. 1 セマンティックバージョニングの定義

List sort(List ls)

List sort(List ls)

を「X.Y .Z 」の形で表記する．X, Y , Z はすべて非負整数であvoid write(int x)

void write(int x)

り，それぞれメジャーバージョン，マイナーバージョン，パッXML get(Path url)

JSON get(Path url)

チバージョンという．最初のリリースに与えるバージョンはVer. 1.0.0

Ver. 2.0.0

セマンティックバージョニング [1] では，1 つのバージョン

1.0.0 とし，以後のリリースに与えるバージョンは，現在のバーライブラリ全体の後方互換性はない

ジョンを基準に次のように決定する．
メジャーリリース 公開されている API に後方互換性のない

図 1 ライブラリ単位でのバージョニング変更が取り入れられたとき，メジャーバージョンを 1 増加させ，マイナーバージョンとパッチバージョンを 0 にする．

次に，ライブラリをリリースする際にバージョニングは人のマイナーリリース 公開されている API に後方互換性のある手で主観的に行われることが多い．例えば，Google Guava と変更が取り入れられたとき，あるいは新たに機能が公開された

いうライブラリではバージョニングのポリシーとしてセマン

とき，マイナーバージョンを 1 増加させ，パッチバージョンをティックバージョニングを用いることが定められている [4] が，0 にする．

ツールなどの指定や推薦はされていない．これは，バージョニ

パッチリリース 誤った振る舞いを修正する後方互換性のあるングを自動化したり補助したりといったツールが開発されてい変更が取り入れられたときに限り，パッチバージョンを 1 増加ない，あるいはそれが普及していないことが理由としてあるとさせる．

考える．その一方で例えばコーディング規約やソフトウェアテメジャーバージョン，マイナーバージョン，パッチバージョストに関しては，コーディング規約が守られているか検証するンを増加させる変更を，それぞれメジャーレベル，マイナーレツール（例えば [5]）やテストを自動化するライブラリ（例えベル，パッチレベルの変更という．メジャーバージョンリリー

ば [6]）が存在する．

スにマイナーレベルやパッチレベルの変更を含むことや，マイ別の問題として，セマンティックバージョニングが遵守されナーリリースにパッチレベルの変更を含むことは許可されてていたとしても，図 1 のようにメジャーリリースで行われた変いる．

更の中には後方互換性のあるもの（図 1 の例では sort(List)

バージョンの比較は，メジャーバージョン，マイナーバージョおよび write(int)）が含まれている可能性がある [2]．これはン，パッチバージョンの順に見て，最初に異なる部分の数値をセマンティックバージョニングの定義で許可されていることだ比較することで行う．例えば 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1 のが，メジャーリリースされたライブラリを利用していても，そようになる．のリリースで変更された機能のうち後方互換性のなくなった機[1] ではこの他にプレリリースの扱いなど，いくつかの仕様能は使用していない可能性がある．ライブラリの変更内容は，が定められているが，本研究では以上で定義されるバージョン

リリースノートなどが用意されていればそれを参照することでのみを取り扱う．

確認できるが，用意されていない場合や変更点が網羅しきれて2. 2 セマンティックバージョニングは遵守されていないいない可能性が考えられる．これについても自動的に変更点をセマンティックバージョニングの原則が実際のプロジェクト列挙することによって，リリースノートの網羅性を担保したりにおいて遵守されているか調査した研究 [2] がある．文献 [2] は，作成を補助したりすることにつながると考えられる．

本来後方互換性を持つべきであるマイナーリリースの 35.7%，含まれており，マイナーリリースやパッチリリースには平均3. メソッドレベルセマンティックバージョニ
ング

で約 30 個の後方互換性のない変更が含まれているという調査

本研究では，前章で述べた問題点を解消するために，メソッ結果を報告している．また，セマンティックバージョニングはド単位でセマンティックバージョニングを行い，各メソッド徐々に守られるようになってきているが，その速さは緩やかでにバージョンを与える手法を提案する．以下，この手法を「メあると報告している．

ソッドレベルセマンティックバージョニング」と呼ぶ．

パッチリリースの 23.8% に後方互換性のない変更が 1 つ以上

2. 3 バージョニングの問題点

従来のバージョニングでは図 1 のようにライブラリ単位でしバージョニングにはいくつかの問題点があると考える．

か後方互換性を示すことができないが，メソッドレベルセマン

まず，前節で述べたようにセマンティックバージョニングはティックバージョニングを行うことによって，図 2 のように後遵守されていないことが少なくない．そのため，後方互換性が方互換性がなくなったメソッド（図の例では get(Path)）を具あるはずのマイナーリリースやパッチリリースが行われたライ体的に提示できるようになる．

ブラリをアップデートした際に，実際には後方互換性がなかっ3. 1 前たためにエラーや不具合が発生してソースコードを修正しなけ

提案手法は「メソッド」という名称のとおり，ある一連の手続提ればならなくなることが発生し得る．

—2—後方互換性がある
メソッド

コミット
タグ

List sort(List ls)…1.0.0

1.1.0… List sort(List ls)

void write(int x) …1.0.0

1.0.1… void write(int x)

XML get(Path url) …1.0.0

2.0.0… JSON get(Path url)

Ver. 1.0.0

後方互換性がない
メソッド

ブランチ

v1.1.02d3acf9

5e3ee11420eac9Ver. 2.0.0
v1.0.0

図 2 メソッド単位でのバージョニング

30e367cd6016bc

図 3 コミットグラフの例

きに名前を付けて他の場所から呼び出せる機能を持つ言語を前提とする．また，バージョン管理システムを用いてソースコードのバージョン管理が行われていることを前提とする．

チバージョンを 1 増加させる．

3. 2 アルゴリズム

削除メソッド各メソッドのバージョンを以下の手順で決定する．

せる．

（ 1 ） メソッドの追跡処理の都合上メジャーバージョンを 1 増加さ

4. Java メソッド自動バージョニングツール（ 2 ） バージョンの決定各手順について説明する．

本研究では，バージョン管理システムの 1 つである Git で(1) メソッドの追跡バージョン管理が行われている Java 言語のソースコードに対一般に，1 つのソースコードファイルには複数のメソッドの定して，メソッドレベルセマンティックバージョニングを自動的義が含まれる．そのため，ソースコードからそれぞれのメソッに適用するツールを Java 言語を用いて作成した．以下ではこドの情報を抽出し，変更前後のソースコードにおけるメソッドれを「提案ツール」と呼ぶ．提案ツールでプログラムから Gitの対応関係を調べる必要がある．提案手法では，ソースコードを操作するためのライブラリとして JGit [8] を採用した．

からメソッドを抽出し，2 つのソースコード間における対応関係を以下のように割り出す．

4. 1 ツールの概要
提案ツールの入力は Java 言語のソースコードを含む Git リ

次に，ソースコード A と B において対応するメソッドの組をポジトリであり，出力はメソッドレベルセマンティックバー求める．ソースコード A と B でメソッドのシグネチャが同じジョニングの結果である．入力された Git リポジトリのソースものは対応すると考えるのが自然であろう．一方，メソッド名

コードにおいて定義されているメソッドのバージョンを計算すが変更された場合など，シグネチャは異なるが「同じ」メソッ

る．2 章で述べたセマンティックバージョニングの定義ではリドであるとすべき場合も考えられる．これについては，A と Bリース毎にバージョニングを行うとされているが，提案ツールにおけるメソッドのボディの類似度を基準にメソッドが対応しではコミット毎にセマンティックバージョニングを行う．ているかどうかを判断する．

(2) バージョンの決定
メソッドの対応関係から，ソースコード A から B にかけて

4. 2 処理の流れ提案ツールが入力リポジトリに対して行う処理の流れを次に示す．

変更されたメソッドを以下の 4 つに分類できる．

Step 1 コミット履歴を取得

追加メソッド 新たに追加されたメソッド

Step 2 メソッドの追跡

改名メソッド シグネチャが異なるメソッド

Step 3 バージョンの決定

修正メソッド シグネチャが同じメソッド
削除メソッド 削除されたメソッド
この分類をもとに，ソースコード B における各メソッドのバージョンを以下のように定める．

Step 2 と Step 3 は 3. 2 節で述べたアルゴリズムに対応する．
以下，各 Step の具体的な処理について述べる．

Step 1: コミット履歴を取得
Git ではコミットを枝分かれさせてブランチ (branch) を作っ

追加メソッド 1.0.0 とする．

たり，複数のブランチを 1 つのコミットに統合（マージ，merge）

改名メソッド メソッドのシグネチャが変更された場合，あるさせたりでき，一般にコミットの履歴は図 3 のようなグラフに

いはメソッドを呼び出せる範囲が狭まった場合はメジャーバーなる．そのため，どのブランチを解析するか，枝分かれした部ジョンを 1 増加させる．そうでない場合で，変更がバグ修正で分をどのように解析するかという問題が生じる．

なければマイナーバージョンを，バグ修正であればパッチバー

提案ツールは，既定のブランチである master ブランチのコジョンを 1 増加させる．

ミットを解析し，枝分かれについては各コミットのファースト修正メソッド 変更に後方互換性がない場合はメジャーバーペアレントのみを解析することにした．ここで，master ブラジョンを 1 増加させる．後方互換性がある場合は，変更がバグンチの最新コミットからファーストペアレントを辿り，古いコ

修正でなければマイナーバージョンを，バグ修正であればパッミットから順に並べたものを「（master ブランチの）コミット—3—

📁 git-repo/├─📁 .git/└─📁 foo/└─📁 bar/├─ Fuga.java└─ Hoge.java
git-repo/foo/bar/Fuga.java
package com.example.something;class Fuga {public int add(int x, int y) {return x + y;}public int piyo(String s) {return s.length();}}📁 historage-repo/├─📁 .git/├─📁 foo_bar_Fuga.java/│ ├─ package│ └─📁 [CN]/│└─📁 Fuga/│└─📁 [MT]/│├─📁 add(int,int)/││ ├─ body││ ├─ modifiers││ ├─ parameters││ └─ return│└─📁 piyo(String)/│└─ ……
└─📁 foo_bar_Hoge.java/├─ package└─📁 [CN]/└─ ……

図 4 Git リポジトリ（左）を変換した Historage リポジトリ（右）Step 3: バージョンの決定
Step 2 で求めたメソッドの対応関係から，3. 2 節の (2) で述べた方法に従ってバージョンを決定する．なお，提案ツールでは，メソッドの返り値の型が変更された場合あるいはアクセス修飾子が狭まった場合に後方互換性がない変更が行われたとする．

5. 実験

提案手法および提案ツールの有用性を示すために，バージョン管理システム Git で管理されている Java 言語で書かれたライブラリがセマンティックバージョニングに基づいていると仮定して，それに従っていないリリースを検出する実験を行った．

履歴」と呼ぶ．なお，コミットの「ファーストペアレント」とはすなわち，本来後方互換性があるはずのマイナーリリースおよそのコミットが行われた際に HEAD が指していたコミットでびパッチリリースにおいて，後方互換性のない変更が行われた

ある [9]．例えば，図 3 におけるコミット 2d3acf9 のファーストpublic メソッドを検出する実験を行った．以下では，本実験でペアレントはコミット 5e3ee11 であり，コミット 5e3ee11 の検出するリリースおよびメソッドを「セマンティックバージョファーストペアレントはコミット 420eac9（コミット 420eac9

ニングに違反した」リリースおよびメソッドと呼ぶ．

からブランチ topic をマージした場合）である．以下，コミット履歴において古い方から n 番目のコミットを「n 番目のコミット」と呼ぶ．

5. 1 実 験 対 象
本実験では，先行研究 [2] において研究対象に用いられている

Maven Repository [13] にあるライブラリのうち利用数の多い

Step 1 ではコミットを遡りながら直近のタグも取得する．タ

表 1 に示す 9 つのライブラリを実験対象とした．より多くのソグとは Git においてコミットに付けられる別名で，例えば図フトウェアで利用されているライブラリにおけるセマンティッ

3 においてコミットを示す丸の左側に書かれた「v1.0.0」やクバージョニングの違反の影響が大きいと考えられるため，こ「v1.1.0」である．のような選定基準とした．

Step 2: メソッドの追跡
提案ツールでは，入力された Git リポジトリを Historage リ

表 1 の項目名で用いた表現とその意味は以下のとおりである．
対象範囲

開発者がタグとして設定したバージョンのうち，本ポジトリ [10] に変換することでソースコードからメソッドの情実験で対象とした範囲報を抽出する．Historage はメソッドレベルでバージョン管理をリリース数

対象範囲で行われたリリースの回数行える Git ベースのバージョン管理システムである．提案ツー

メソッド数

public メソッドの数

ルでは Kenja [10] [11] によって Git リポジトリを Historage リポジトリに変換する．Git リポジトリを Kenja に入力すると，ソースコードからメソッドの情報が抽出されて図 4 のような構造のディレクトリが構築される．

ライブラリ名を省略する際は，表 1 でライブラリ名の左に記載した L1–L9 を用いる．
実験対象のライブラリのうち Google Guava に関しては，セマンティックバージョニングを用いてバージョニングを行う[11] で公開されている Kenja が取得するメソッドの情報はメことがリリースポリシー [4] に明言されている．また，Apache

ソッドの引数とボディ（図 4 の parameters ファイルと body

Commons プロジェクトのライブラリ (L1–L3) に関しては，セファイル）のみであり，返り値の型やアクセス修飾子の情報はマンティックバージョニングに相当すると考えられるガイドラ取得しない．メソッドの引数とボディだけではメソッドの後方イン [14] が制定されていることを確認した．

互換性を判断するためには不十分であり，返り値の型およびア

表 1 に示したように一部のリリースにはタグが設定されてクセス修飾子の情報も考慮する必要があると考えられる．提案ツールでは Kenja が利用する Java 言語のパーサ [12] を返り値の型およびアクセス修飾子の情報（図 4 の return ファイル

表 1 実験対象のライブラリと規模ライブラリ名対象範囲

リリース数 メソッド数

および modifiers ファイル）も取得するように修正して利用

L1 Apache Commons IO 1.0.0– 2.5.0

143,183

する．

L2 Apache Commons Lang 1.0.0– 3.7.0

1913,150

L3 Apache Log4j 2

2.0.0–2.10.0

1716,508

L4 Google Guava

1.0.0–23.6.0

2934,287

L5 Jackson Databind2.0.0– 2.9.1

28

14,359ド gn−1 について，body ファイルがバイト数を基準に 60% 以

L6 Java Servlet API

3.0.1– 4.0.0

3190

上同じであるとき fn と gn−1 が同じメソッドであるとし，メL7 JUnit4

3.8.2–4.12.0

10

5,567

ソッドのシグネチャが変更されたものとする．なお，60% とい

L8 Logback

1.0.0– 1.2.2

232,408

う数字は JGit の設定の既定値である．

L9 Mockito

1.0.0– 2.1.0

35

10,785

提案ツールでは，コミット履歴の n 番目のコミット cn におけるメソッド fn とその 1 つ前のコミット cn−1 におけるメソッ—4—

いなかったが，タグが設定されていたリリースを対象に実験

9778L1を行った．また，ベータ版などのプレリリースやメジャーバーL2

ジョンが 0 であるリリースは対象としなかった．

69L3

対象のライブラリに対して，以下の手順で実験を行った．

Step 1 提案ツールを実行し，各メソッドの後方互換性を調査
Step 2 ライブラリ全体の後方互換性を決定
Step 3 実際のライブラリのバージョン変化と比較
ここでは Step 2 と Step 3 について詳しく述べる．

Step 2: ライブラリ全体の後方互換性を判定
開発者が与えたライブラリのバージョンから判断される後方互換性と比較するために，リリースに 1 つでも後方互換性が失

ライブラリ

5. 2 実 験 方 法

2,617

330

L4810
3,930

6

L516

L60
2

1,720

L7137
133

L899

メジャーリリース
マイナーリリース・パッチリリース

348

L91,103
0

1,534

1000

2000

3000

4000

メソッド数

われたメソッドを含むとき，そのライブラリ全体の後方互換性

図 5 後方互換性のない変更が行われたメソッドが失われたと判定した．
実験対象のライブラリのうち Java Servlet API を除くライブラリではソフトウェアテストが実施されており，JUnit [6] を来後方互換性のあるマイナーリリースあるいはパッチリリース利用したソースコードが含まれていた．JUnit ではテストケーで行われたことのあるメソッドの数，下の棒（青色）は後方互

スを public メソッド（テストメソッド）として定義するため，換性のない変更がすべて正しくメジャーリリースにおいて行わ

単に public なメソッドを収集するとテストメソッドが含まれれたメソッドの数を示す．てしまう．テストメソッドはあくまでソフトウェアテストに用

Google Guava (L4) は後方互換性のない変更が行われたメいられるコードであり，実際のソフトウェア開発においてライソッドが最も多いが，マイナーリリースやパッチリリースにおブラリのテストコードを利用することはほとんどないと考えらいて行われたメソッドは最も少ないライブラリであることがれる．したがってライブラリ全体の変更のレベルを求める際に分かった．一方で Apache Commons Log4j 2 (L3) や Jackson

テストメソッドの後方互換性を考慮する必要はないと判断し，Databind (L5) は後方互換性のないほとんどの変更が本来後方以下のメソッド呼び出しを含むメソッドを除外してライブラリ互換性のあるリリースで行っていることが分かった．

全体の後方互換性を判定した．

6. 考

assertArrayEquals,

assertEquals,

assertFalse,

assertNotNull,assertNotSame,

assertNull,assertSame,

assertThat,

assertTrue.

Step 3: 実際のライブラリのバージョン変化と比較

察

表 3 の結果から，1 リリース当たり平均 27.0 個のメソッドが表 2 セマンティックバージョニングに違反したリリースの数
ライブラリ

本来はすべての変更に後方互換性があるはずのマイナーリ
リースおよびパッチリリースについて，実際には後方互換性のない変更が public メソッドに行われたリリースとその原因となったメソッドを検出した．

Rall

Rincor割合

Apache Commons IO

13753.8%

Apache Commons Lang

17847.1%

Apache Log4j 21616 100.0%

Google Guava

2827.1%

5. 3 実 験 結 果

Jackson Databind

272074.1%

まず，セマンティックバージョニングに違反していると判断

Java Servlet API

2150.0%

されたリリースの数と総リリース数に対する割合を表 2 に示す．

JUnit49666.7%

Rall は表 1 に示した区間の最初のバージョンを除いたリリース

Logback

22

1777.2%数，Rincor はセマンティックバージョニングに違反したリリー

Mockito34

2264.7%スの数である．実験対象のすべてのライブラリにおいてセマンティックバージョニングに違反したリリースが存在し，その表3

後方互換性のない変更が行われたことがあるメソッド

ライブラリ

MmajorMincor割合

割合は Apache Log4j 2 や Jackson Databind で多く，Google

Apache Commons IO

1757844.6%

Guava で少ない結果となった．

Apache Commons Lang

2947

330

11.2%
92.2%

次に，後方互換性のないメソッドの変更がどのレベルのリ

Apache Log4j 2879810

リースで行われているかを調べた．その結果を表 3 にまとめる．

Google Guava

3936

60.2%

Mmajor は後方互換性のない変更が行われたことがある publicJackson Databind

1736

1720

99.1%

メソッド数，Mincor は後方互換性のない変更がマイナーリリースあるいはパッチリリースで行われたことがある public メ
ソッド数である．これを棒グラフにしたものを図 5 に示す．各Java Servlet API
JUnit42270

2 100.0%13349.3%

Logback

447

348

77.9%

Mockito

2637

1103

41.8%

項目の上の棒（橙色）は後方互換性のないメソッドの変更が本—5—

マイナーリリースやパッチリリースにおいて行われていることが分かった．これは先行研究 [2] で Clirr を用いて行われた実験結果と概ね一致する．ただし，提案ツールは Clirr よりも細かい間隔でメソッドの対応関係を調べているため，メソッドの追跡精度が向上した可能性が考えられる．そのため，この違いを評価するために本実験の結果を精査し，追加の実験を行う必要があると考える．

7. 妥当性への脅威
7. 1 メソッドの後方互換性
提案ツールではシグネチャや返り値の型が変更された場合に後方互換性がないと判断してバージョニングを行っている．しかしより正確には，型（クラス）の継承関係やメソッドの返り値自体の変化，さらには副作用なども考慮する必要があると考えられる．これらを考慮した場合に実験結果が変わる可能性がある．

7. 2 「バグ修正コミット」の定義
提案ツールでは，変更のレベルのうち後方互換性のあるマイナーレベルとパッチレベルの分類に変更が行われたコミットのコミットメッセージをもとにその変更がバグ修正であるかどうかを判断した．本研究では後方互換性の有無を議論の焦点としたため，また，正確にバグ修正であるかどうかを判断することは困難であるとの考えからこのような実装とした．しかし，バグ修正が行われたコミットのコミットメッセージに特定の単語が含まれていることを前提とする是非について議論の余地があると考えられる．

7. 3 他のプログラミング言語におけるメソッドレベルセマ
ンティックバージョニング
本研究で行ったメソッドレベルセマンティックバージョニン

較する評価実験•

メソッドの後方互換性の判断において，クラスの継承関係やメソッドの返り値自体の変化および副作用についても考慮•

メソッドレベルセマンティックバージョニングの結果をソフトウェア開発者にどのようにフィードバックするか検討
謝辞

本研究は，日本学術振興会科学研究費補助金基盤研究（S）（課題番号：JP25220003）の助成を得て行われた．
文

献[1] “Semantic Versioning 2.0.0”. https://semver.org/spec/
v2.0.0.html[2] S. Raemaekers, A. Van Deursen, and J. Visser, “Semantic versioning versus breaking changes: A study of themaven repository,” Source Code Analysis and Manipulation(SCAM), 2014 IEEE 14th International Working Conference onIEEE, pp.215–224 2014.
[3] “Clirr”. http://clirr.sourceforge.net/index.html[4] “ReleasePolicy ・ google/guava Wiki”．https://github.com/
google/guava/wiki/ReleasePolicy[5] “Checkstyle”. http://checkstyle.sourceforge.net/[6] “JUnit”. https://junit.org/[7] “Defining Methods (The Java™ Tutorials > Learning
the Java Language > Classes and Objects)”. https://
docs.oracle.com/javase/tutorial/java/javaOO/methods.html[8] “JGit”. http://www.eclipse.org/jgit/[9] S. Chacon and B. Straub, Pro git, Apress, 2014.
[10] K. Fujiwara, H. Hata, E. Makihara, Y. Fujihara, N.
Nakayama, H. Iida, and K. Matsumoto, “Kataribe: A hosting service of historage repositories,” Proceedings of the11th Working Conference on Mining Software RepositoriesACM, pp.380–383 2014.
[11] “Kenja”. https://github.com/niyaton/kenja[12] “kenja-java-parser”. https://github.com/niyaton/kenja-javaparser[13] “Maven Repository”. https://mvnrepository.com/[14] “Apache Commons – Versioning Guidelines”. https://commons.apache.org/releases/versioning.html

グの定義は，メソッドに相当する機能を備えていれば適用可能であるが，それを適用するツールおよびそれを用いた実験はJava 言語のみを対象に行った．そのため，他のプログラミング言語に対してメソッドレベルセマンティックバージョニングを適用した場合に実験結果が変わる可能性がある．

8. あ と が き
本研究では，メソッドレベルセマンティックバージョニングを提案し，それを Java 言語のメソッドに適用するツールを作成した．また，作成したツールを実際のライブラリに対して用いてメソッドレベルセマンティックバージョニングを行い，誤ったバージョニングが行われているリリースとその原因となったメソッドを検出する実験を行った．それにより，先行研究 [2]が示した結果と同程度に検出結果が得られたため，提案手法に一定の有用性があると考えられる．
提案ツールはコミット単位でメソッドの追跡と後方互換性の判定を行うため，これらをリリース単位で行う Clirr よりも正確にメソッドの追跡が行えることが期待されるが，本研究ではこの点についての評価実験が行えていない．
これを踏まえて以下の 3 点を今後の課題として挙げる．

•提案ツールおよび Clirr によるメソッドの追跡精度を比—6—