Download pdf - Slides for Semantic Versioning versus Breaking Changes: A Study of the Maven Repository

SemVerと互換性をMavenで調査

大阪大学大学院 CS専攻楊嘉晨

背景著者情報と出典セマンティックバージョニングSemVerと APIの後方互換性

Research Questions調査目的と対象調査項目

調査手法調査手法の概要Maven中央リポジトリAPIの後方互換性を判断する基準バージョン番号の比較ソースコードの比較と廃止パターン

統計的な結果バージョン文字列のパターン互換性が有無の API変更

調査項目の結果RQ1:SemVer原則が従われているかRQ2:時間を亘って変わるかRQ3:依存関係がどう更新されるかRQ4:廃止予定タグが使われているか

議論と妥当性への脅威SemVer原則を守れない原因リリースの間隔と編集の規模初期開発段階のリリース妥当性への脅威

結論

2015年 05月 28日（木）

1/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Semantic Versioning versusBreaking Changes: A Study of the

Maven RepositoryMD輪講

博士後期課程 3年楊　嘉晨大阪大学大学院コンピュータサイエンス専攻楠本研究室

2015年 05月 28日（木）









結論

2015年 05月 28日（木）

2/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


Research Questions

調査手法

統計的な結果

調査項目の結果

議論と妥当性への脅威

結論









結論

2015年 05月 28日（木）

3/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

著者情報と出典Authors and Publication

Semantic Versioning versus BreakingChanges: A Study of the Maven Repository¹出典 SCAM 2014, Victoria, Canada著者 Steven Raemaekers†,

Arie van Deursen‡,Joost Visser†

† Software Improvement Group, Amsterdam,The Netherlands

‡ Technical University Delft, The Netherlands¹Steven Raemaekers, Arie van Deursen, and Joost Visser. “Semantic versioning versus breaking changes: a study of the Maven

Repository”. In: Source Code Analysis and Manipulation (SCAM), 2014 IEEE 14th International Working Conference on. IEEE. 2014,

pp. 215–224.









結論

2015年 05月 28日（木）

4/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

セマンティックバージョニングBackground: Semantic Versioning

3.19.2バージョンナンバーを上げるには、²

major APIの変更に互換性のない場合minor 後方互換性があり機能性を追加した場合patch 後方互換性を伴うバグ修正をした場合

²http://semver.org/lang/ja/

http://semver.org/lang/ja/









結論

2015年 05月 28日（木）

4/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.














結論

2015年 05月 28日（木）

4/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.




これらルールは既存のソフトウェアに広く使われてあり、全てのソフトウェアに普及すべし

Tom Preston-Werner氏, Gravatars及び GitHubの共同創設者²http://semver.org/lang/ja/










結論

2015年 05月 28日（木）

4/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.




これらルールは既存のソフトウェアに広く使われてあり、全てのソフトウェアに普及すべし

Tom Preston-Werner氏, Gravatars及び GitHubの共同創設者²http://semver.org/lang/ja/










結論

2015年 05月 28日（木）

4/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.




実際、バージョンナンバーは本当にセマンティックバージョニング（以下 SemVerと略称）の原則を守っているか？











結論

2015年 05月 28日（木）

5/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

SemVerと互換性Semantic Versioning and API Compatibility

ソフトウェアやライブラリーのユーザーにとって、APIの後方互換性後方互換性後方互換性後方互換性後方互換性後方互換性は重要である

ソフトウェア A

ライブラリー B: 1.2


ライブラリー B: 2.0SemVerの原則が守っていれば、安心で依存関係のライブラリーをアップグレードすることができる









結論

2015年 05月 28日（木）

5/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.















結論

2015年 05月 28日（木）

5/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.















結論

2015年 05月 28日（木）

5/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.















結論

2015年 05月 28日（木）

6/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景


調査手法

統計的な結果



結論









結論

2015年 05月 28日（木）

7/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

調査目的と対象Goal and Research Targets

目的バージョン番号を上げる際に API互換性がSemVer原則に従われているかどうか

対象 Maven中央リポジトリ³にあるほぼ全ての OSS

Maven中央リポジトリを対象とする原因• プロジェクト間の依存関係が記述される• 一箇所に集まる• バージョン番号も明記されています

³http://search.maven.org/

http://search.maven.org/









結論

2015年 05月 28日（木）

7/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

調査目的と対象Goal and Research Targets

目的バージョン番号を上げる際に API互換性がSemVer原則に従われているかどうか

対象 Maven中央リポジトリ³にあるほぼ全ての OSS

Maven中央リポジトリを対象とする原因• プロジェクト間の依存関係が記述される• 一箇所に集まる• バージョン番号も明記されています

³http://search.maven.org/

http://search.maven.org/









結論

2015年 05月 28日（木）

8/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

調査項目Research Questions

RQ1 互換性に関する SemVer原則はどのぐらい従われている？

RQ2 SemVer原則に従うソフトウェアは時間に亘って増えているか？

RQ3 新しいバージョンへの依存関係はどう更新されてるか？最新版を使わぬ要因は何がある？

RQ4 廃止予定 (deprecation)のタグは実際にどう使われているのか？

廃止予定 @deprecatedAPI互換性を破る前に、幾つかのバージョンに予め廃止を予定したメソッド等につけるアノテーション









結論

2015年 05月 28日（木）

8/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

調査項目Research Questions

RQ1 互換性に関する SemVer原則はどのぐらい従われている？

RQ2 SemVer原則に従うソフトウェアは時間に亘って増えているか？

RQ3 新しいバージョンへの依存関係はどう更新されてるか？最新版を使わぬ要因は何がある？

RQ4 廃止予定 (deprecation)のタグは実際にどう使われているのか？

廃止予定 @deprecatedAPI互換性を破る前に、幾つかのバージョンに予め廃止を予定したメソッド等につけるアノテーション









結論

2015年 05月 28日（木）

9/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景

Research Questions


統計的な結果



結論









結論

2015年 05月 28日（木）

10/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

調査手法の概要

中央リポ

バイナリー

メタ情報

ソース

互換性

バージョン番号

リリース日時

依存関係

AST変更@Deprecated









結論

2015年 05月 28日（木）

11/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Maven中央リポジトリ2011年 7月 11日の時点のMaven中央リポジトリのスナップショット ⁴を取ってきて⁵、pom.xmlを解析し、プロジェクト間に依存関係でリンク付け⁶

プロジェクト数バイナリー jar ソース jar規模 22,205 148,253 101,413　

平均、プロジェクト毎に 6.7リリース⁴http://juliusdavies.ca/2013/j.emse/bertillonage/

maven.tar.gz⁵Julius Davies et al. “Software bertillonage: finding the provenance of an entity”. In: Proceedings of the 8th working

conference onmining software repositories. ACM. 2011, pp. 183–192.⁶Steven Raemaekers, Arie van Deursen, and Joost Visser. “The maven repository dataset of metrics, changes, and

dependencies”. In: Proceedings of the 10th Working Conference on Mining Software Repositories. IEEE Press. 2013, pp. 221–224.

http://juliusdavies.ca/2013/j.emse/bertillonage/maven.tar.gz

http://juliusdavies.ca/2013/j.emse/bertillonage/maven.tar.gz









結論

2015年 05月 28日（木）

12/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

APIの後方互換性を判断する基準Determining backward incompatible API changes

厳密に API互換性の有無を判断することは困難• 意味的に解析や、実際にビルド・テストする必要

代わりに本研究ではバイナリー互換性を判断基準とするJava言語仕様にバイナリー互換性の定義 ⁷APIに変更する前後に、リンクする際にエラーが起こらないことはバイナリー互換性があること

本研究に使った定義再度コンパイルし直す必要がない APIの変更⁸

⁷http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html

⁸http://wiki.eclipse.org/EvolvingJava-basedAPIs

http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html


http://wiki.eclipse.org/Evolving Java-based APIs









結論

2015年 05月 28日（木）

12/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

APIの後方互換性を判断する基準Determining backward incompatible API changes

厳密に API互換性の有無を判断することは困難• 意味的に解析や、実際にビルド・テストする必要

代わりに本研究ではバイナリー互換性を判断基準とするJava言語仕様にバイナリー互換性の定義 ⁷APIに変更する前後に、リンクする際にエラーが起こらないことはバイナリー互換性があること

本研究に使った定義再度コンパイルし直す必要がない APIの変更⁸

⁷http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html

⁸http://wiki.eclipse.org/EvolvingJava-basedAPIs



http://wiki.eclipse.org/Evolving Java-based APIs









結論

2015年 05月 28日（木）

13/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Clirr:公開 APIに変更を検出ツール ⁹Clirr: Tool to Extract API changes

入力:バイナリー Jarファイル、出力:公開 API違い互換性がない互換性があるメソッドの削除メソッドの追加クラスの削除クラスの追加フィルドの削除フィルドの追加引数の型が変更親クラスレスとに追加フィルドの型が変更定数の値が変更　総数：23 総数：20

安全側に立って、検出した互換性がない修正は絶対正しいが、互換性がある変更に間違いがある

⁹http://clirr.sourceforge.net









結論

2015年 05月 28日（木）

14/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

バージョン番号の比較Determining subsequent versions and update types

以下の要素でライブラリーのバージョンを特定groupId artifactId versionorg.springframework spring-core 2.5.6

バージョン番号の比較は Artifact API ¹⁰を使いますフォーマットは MAJOR.MINOR.PATCH、PATCHがない場合に 0とみなすプレリリース（1.2.3-beta1や 1.2.3-snapshot）は対象から外す

¹⁰http://maven.apache.org/ref/3.1.1/maven-artifact

http://maven.apache.org/ref/3.1.1/maven-artifact









結論

2015年 05月 28日（木）

14/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.














結論

2015年 05月 28日（木）

14/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.














結論

2015年 05月 28日（木）

14/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.














結論

2015年 05月 28日（木）

15/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

ソースコードの比較と廃止パターンDetecting changed functionality and deprecation patterns

ソースコードはどのぐらい変更したのかをChangeDistiller¹¹で比較しますChangeDistiller入力：２つバージョンのソースコード出力：AST上のノードの編集スクリプト

廃止 APIはキーワード @Deprecatedで検索し、該当するソースファイルを JDTで解析して、廃止APIのパターンを検出します。

¹¹Beat Fluri et al. “Change distilling: Tree differencing for fine-grained source code change extraction”. In: Software

Engineering, IEEE Transactions on 33.11 (2007), pp. 725–743.









結論

2015年 05月 28日（木）

15/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

ソースコードの比較と廃止パターンDetecting changed functionality and deprecation patterns

ソースコードはどのぐらい変更したのかをChangeDistiller¹¹で比較しますChangeDistiller入力：２つバージョンのソースコード出力：AST上のノードの編集スクリプト

廃止 APIはキーワード @Deprecatedで検索し、該当するソースファイルを JDTで解析して、廃止APIのパターンを検出します。

¹¹Beat Fluri et al. “Change distilling: Tree differencing for fine-grained source code change extraction”. In: Software

Engineering, IEEE Transactions on 33.11 (2007), pp. 725–743.









結論

2015年 05月 28日（木）

16/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景

Research Questions

調査手法




結論









結論

2015年 05月 28日（木）

17/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

バージョン文字列のパターン

69%のバージョン文字列は SemVerのフォーマットになっています。22.3%のバージョン文字列はプレリリース（4と 5）である。29%のライブラリーは１つのリリースのみである。









結論

2015年 05月 28日（木）

18/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

互換性が有無の API変更









結論

2015年 05月 28日（木）

18/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


MajorとMinorの使い分けはされていない！









結論

2015年 05月 28日（木）

18/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


MajorとMinorの使い分けはされていない！









結論

2015年 05月 28日（木）

19/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景

Research Questions

調査手法

統計的な結果



結論









結論

2015年 05月 28日（木）

20/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ1:SemVer原則が従われているか

SemVerを従われていれば、Minor/Patchに互換性がない変更はないはずなのに、実際Minor/Patchに平均 30ぐらいの互換性がない変更がある。編集の大きさから見ると、MinorはMajorより大きいが、Patchは相対的に小さい。リリースの間隔から見ると、MinorはMajorより時間がかかる。









結論

2015年 05月 28日（木）

20/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

20/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

21/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ1に対する回答

後方互換性に関するSemVer原則は実際に守られていない！Minorリリースと Patchリリースには、互換性のない変更が平均 30個ぐらいあります。









結論

2015年 05月 28日（木）

21/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


後方互換性に関するSemVer原則は実際に守られていない！Minorリリースと Patchリリースには、互換性のない変更が平均 30個ぐらいあります。









結論

2015年 05月 28日（木）

22/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ2:時間を亘って変わるか









結論

2015年 05月 28日（木）

23/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


SemVer原則を守ることは近年少しぐらい増えているMinorと Patchリリースに互換性のない変更の割合は、2006年の28.4%から、2011年に23.7%になりました。









結論

2015年 05月 28日（木）

23/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


SemVer原則を守ることは近年少しぐらい増えているMinorと Patchリリースに互換性のない変更の割合は、2006年の28.4%から、2011年に23.7%になりました。









結論

2015年 05月 28日（木）

24/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ3:依存関係がどう更新されるか









結論

2015年 05月 28日（木）

25/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ3-1:依存関係が伴う更新される数

互換性がない更新に着目する理由は、依存関係の更新を困難に持たすから、ここで依存関係の更新に関しても調べました。

ソフトウェア Sの更新される際に、依存関係の記述にライブラリー Lを伴って更新された数を調べた。









結論

2015年 05月 28日（木）

26/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ3-2:依存関係が伴う更新の遅延更新の遅延: Sが Lを依存して、Lの最新版 Lnがリリースされたが、その後にリリースされた Sの最新版は古い Loに依存したまま場合、一回の遅延と見なし、遅延の長さは Loと Lnの間のリリースの数として定義。

更新の遅延は互換性のない変更の数とソースコードに対する変更の激しさの関係を、スピアマン相関係数で評価









結論

2015年 05月 28日（木）

27/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ3に対する回答依存関係の更新は多くの場合に、ソフトウェアのMajorリリースにライブラリーのMajorリリースを更新される依存関係が更新するのに遅延が存在され、Patchリリースによく発生する更新の遅延は変化の激しさとの相関は弱いけど存在する









結論

2015年 05月 28日（木）

27/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.










結論

2015年 05月 28日（木）

27/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.










結論

2015年 05月 28日（木）

28/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

廃止予定タグの正しい使い方

バージョン: 1.01 class foo{23 public void4 function(){5 //...6 };789

1011 }

バージョン: 1.11 class foo{2 + @Deprecated3 public void4 function(){5 //...6 };7 + public Object8 + functionEx(){9 + //...

10 + };11 }

バージョン: 2.01 class foo{2 - @Deprecated3 - public void4 - function(){5 - //...6 - };7 public Object8 functionEx(){9 //...

10 };11 }









結論

2015年 05月 28日（木）

29/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

RQ4:廃止予定タグが使われているか22,205プロジェクトの内、1196 (5.4%)は少なくとも一回メソッドに廃止予定のタグがつけられていた

1,2,3 privateや廃止と関係ないメソッドは対象外5,6,7 間違い使い方4,8 正しい使い方9 廃止予定がキャンセルした









結論

2015年 05月 28日（木）

29/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

29/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

29/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

29/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.











結論

2015年 05月 28日（木）

30/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


プログラマーは廃止予定のタグを殆ど使われていない。

使われていても、正しく使われていない。









結論

2015年 05月 28日（木）

30/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.


プログラマーは廃止予定のタグを殆ど使われていない。

使われていても、正しく使われていない。









結論

2015年 05月 28日（木）

31/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景

Research Questions

調査手法

統計的な結果



結論









結論

2015年 05月 28日（木）

32/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

SemVer原則を守れない原因Low adherence explained

Javaのモジュールシステムに可視性の設定はプログラマーの必要に満たせない。「内部専用」のパケージは公開されてしまったことが多い。

software

library

internal external

UseImpl PublicClassImpl PublicClass

実際の使い方と潜在的な使い方の違いもあります









結論

2015年 05月 28日（木）

33/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

リリースの間隔と編集の規模

直感で考えると、MajorリリースはMinorリリースより時間がかかるはずなのに、実際のデータから見る限り、Minorリリースのほうが時間がかかります。

推測: Majorリリースは意図的互換性を破るために作ることが多く、機能追加はその後にあるMinorリリースに行う。

ソースコードの編集の規模からもこの傾向が見えます：Minorリリースのほうが編集が多くされます。









結論

2015年 05月 28日（木）

33/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.













結論

2015年 05月 28日（木）

33/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.













結論

2015年 05月 28日（木）

34/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

初期開発段階のリリース

SemVerの説明によると「Major番号は 0の場合(0.y.z)、互換性を守らないことは許されます」

今回の調査にこのルールを考慮していない。数だけを調べたら、Major番号は 0のリリース数は10.44% (13,162 / 126,070)があります。









結論

2015年 05月 28日（木）

34/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

初期開発段階のリリース

SemVerの説明によると「Major番号は 0の場合(0.y.z)、互換性を守らないことは許されます」

今回の調査にこのルールを考慮していない。数だけを調べたら、Major番号は 0のリリース数は10.44% (13,162 / 126,070)があります。









結論

2015年 05月 28日（木）

35/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

妥当性への脅威内部的妥当性記録されたライブラリーのリリース日時が間違えた可能性がある。

• 2,321, 1.5%のバイナリーファイルのリリース日時は2005年 11月 5日になって、データから省いた

• リリース日時の順位とバージョン番号によるソートした順位と一致しないことはある。

外部的妥当性Mavenにある Javaで書かれた OSSだけ対象にした実験結果の再現性スーパーコンピューターで、100計算ノード、合計六ヶ月の計算時間を使って分析した









結論

2015年 05月 28日（木）

36/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

背景

Research Questions

調査手法

統計的な結果



結論









結論

2015年 05月 28日（木）

37/37.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

結論この研究は 22,000超えるMavenにある OSSライブラリーを対象として、バージョン番号と互換性の関係について、SemVerを基準として調査した。発見したことは：

• 互換性がない変更がよくある：13のリリース

• majorバージョンであるかどうかと関わらず、互換性がない変更は同じぐらいに存在する

• 互換性がない変更の存在は新しいライブラリーを使う遅延に影響は小さい

• 廃止予定のタグはあまり使われていない、使った場合でも正しく使われていない