Wiki: /* セマンティックバージョニングにおいて行ってもよいこと */

2025-11-29T19:57:04Z

セマンティックバージョニングにおいて行ってもよいこと

← 古い版		2025年11月30日 (日) 04:57時点における版
84行目:		84行目:

	__FORCETOC__		__FORCETOC__
	[[カテゴリ:C]][[カテゴリ:C++]][[カテゴリ:MFC]][[カテゴリ:Qt]][[カテゴリ:C_Sharp]][[カテゴリ:Python]][[カテゴリ:Electron]][[カテゴリ:Web]]		[[カテゴリ:C]][[カテゴリ:C++]][[カテゴリ:MFC]][[カテゴリ:Qt]][[カテゴリ:C_Sharp]][[カテゴリ:Rust]][[カテゴリ:Python]][[カテゴリ:Electron]][[カテゴリ:Web]]

Wiki: ページの作成:「== 概要 == プロジェクトで使用しているライブラリのバージョンがアップデートされる場合、プロジェクトに影響を与える可能性がある。
しかし、ライブラリのバージョンを固定化すると、プロジェクトで使用しているライブラリのバージョンが更新できなくなり、セキュリティリスクを抱える可能性もある。

このようなリスクを抑えるた…」

2022-12-14T06:04:02Z

ページの作成:「== 概要 == プロジェクトで使用しているライブラリのバージョンがアップデートされる場合、プロジェクトに影響を与える可能性がある。 しかし、ライブラリのバージョンを固定化すると、プロジェクトで使用しているライブラリのバージョンが更新できなくなり、セキュリティリスクを抱える可能性もある。 このようなリスクを抑えるた…」

新規ページ

== 概要 ==
プロジェクトで使用しているライブラリのバージョンがアップデートされる場合、プロジェクトに影響を与える可能性がある。 
しかし、ライブラリのバージョンを固定化すると、プロジェクトで使用しているライブラリのバージョンが更新できなくなり、セキュリティリスクを抱える可能性もある。 
 
このようなリスクを抑えるため、プロジェクトやライブラリのリリースにおいて、バージョン指定に関するルールを決めたものをセマンティックバージョニングと呼ぶ。 
ただし、セマンティックバージョニングを採用している場合でも、その通りにリリースされないライブラリ等が存在するため注意が必要である。 
 
ライブラリの開発者は、バージョニング設定時のルールまで把握しておくことにより、利用者ごとのライブラリの影響を最小限に抑えることができる。 
 
例えば、Composer等がセマンティックバージョニングを採用している。 
 

== 一般的なバージョンの決定方法 ==
バージョニングは、X.Y.Zのように決める。 
X.Y.Zの部分の意味をそれぞれ、以下に示す。 
 
* X
*: メジャーバージョン
*: 大規模な変更が起きて、今までの過去のバージョンとの互換性が失われる場合にメジャーバージョンの数字を上げる。
* Y
*: マイナーバージョン
*: 過去のバージョンとの互換性は失われないが、新機能の開発や機能改善が行われた場合にマイナーバージョンの数字を上げる。
*: 例えば、プロジェクトの影響を最小限に抑えつつ、アップデートする場合にマイナーバージョンを上げる。
* Z
*: バグフィックスバージョン (パッチバージョン)
*: 主にバグ修正のためのバージョン情報である。
*: バグ修正が行われた場合にパッチバージョンの数字を上げる。
*: 企業においてプロジェクトを扱う場合は、バグフィックスバージョンは上げた方がよい。
 

== セマンティックバージョニングの仕様 ==
セマンティックバージョニングにおいて、バージョンの上げ方やルールには仕様が存在する。 
 
==== セマンティックバージョニングにおいて必ず行うこと ====
セマンティックバージョニングにおいて、必ず従わないといけないルールを以下に示す。 
 
* パブリックAPIを宣言する
*: 外部ライブラリは、パブリックAPIを宣言して、外部プログラムから使用されるAPIを作成する必要がある。
*: 
* バージョンはX.Y.Zの形式、かつ、それぞれの数字が非負の整数(正の整数)であること
*: 非負の整数というのは、0以上の整数でなければならないということである。
*: 
* バージョン番号は各数値の先頭にゼロを配置してはならない
*: 例えば、バージョンを01.05.09のようにしてはならない。
*: ただし、1.0.5のようにバージョン番号自体がゼロの場合はよい。
*: 
* 各バージョンは数値的にバージョンアップしなければならない
*: バージョンダウンをしてはならない。
*: 
* 1度リリースされたバージョンに対して修正してはならない
*: いかなる修正もバージョンアップとして対応する。
*: 
* バグフィックスバージョン(パッチバージョン)において、後方互換性を保ったバグ修正を取り込んだ場合のみ、バージョンを上げなければならない
*: パブリックAPI(元のプロダクト)の仕様と同等、かつ、バグ修正のみを行った場合はパッチバージョンを上げる。
*: 
* マイナーバージョンは、後方互換性を保ちつつ機能性をパブリックAPIに追加した場合に上げなければならない
*: パブリックAPI(元のプロダクト)を残しつつ、新規でパブリックAPIを追加した場合等は、マイナーバージョンを上げる。
*: 
* メジャーバージョンは、パブリックAPIに対して後方互換性を持たない変更が取り込まれた場合に上げなければならない
*: 既存のパブリックAPI(元のプロダクト)の仕様と異なる場合には、メジャーバージョンを上げる。
*: 
* メジャーバージョンを上げた場合は、マイナーバージョンおよびバグフィックスバージョンをどちらも0にリセットしなければならない
*: もし、プレリリースバージョンを表現する場合は、バグフィックスバージョンの直後にハイフンとドットで区切られた識別子を追加することで表現してもよい。
*: この時、識別子は必ずASCII英数字(0-9, A-Z, a-z)とハイフン(-)でなければならない。
*: また、識別子は空であっていけない。
*: 数値の識別子はゼロから始めてはいけない。
*: 
*: プレリリースバージョンを付加する場合は無関係であるが、付加する場合は上記のようなルールになる。
*: 例1. 1.0.0-alpha
*: 例2. 1.0.0-alpha.1
*: 例3. 1.0.0-0.3.7
*: 例4. 1.0.0-x.7.z.92
 
上記のルールの他、ビルドメタデータについてのルールもある。 
ただし、ビルドメタデータを付加したバージョンを付けるライブラリは少ない。 
 
==== セマンティックバージョニングにおいて行ってもよいこと ====
* マイナーバージョンは、プライベートコード(外部に公開しないソースコードや機能)内での新しい機能の追加や改善を取り込んだ場合は上げてもよい。 また、バグ修正の変更を含めてもよい。
*: プライベートコード(外部に公開しないソースコードや機能)の改善や機能追加の場合は、マイナーバージョンを上げる。
*: この時、バグ修正を含めてもよい。
*: 
* メジャーバージョンを上げる場合、マイナーおよびパッチレベルの変更も含めてもよい
 

__FORCETOC__
[[カテゴリ:C]][[カテゴリ:C++]][[カテゴリ:MFC]][[カテゴリ:Qt]][[カテゴリ:C_Sharp]][[カテゴリ:Python]][[カテゴリ:Electron]][[カテゴリ:Web]]

開発 - セマンティックバージョニング - 版の履歴

Wiki: /* セマンティックバージョニングにおいて行ってもよいこと */