ForHosting KIT · 開発者向けツール

セマンティックバージョンを major・minor・patch で更新

次のリリース番号を間違いなく求められます。minor の更新で 2.7.4 は 2.8.0 になり、patch は0に戻ります。新しいリリース系列が始まるため、プレリリースやビルドの接尾辞は取り除かれます。ブラウザで無料で使えます。

  • 無料
  • ブラウザで動作
  • 登録不要
  • データは端末の外に出ません
ご利用方法 ウェブAPIメールTelegramアプリ 近日
入力した場合
バージョン
2.7.4
バージョンの上げ方
Minor
結果
元のバージョン
2.7.4
更新後のバージョン
2.8.0

セマンティックバージョン更新ツールは、有効な Semantic Versioning 2.0.0 の文字列と選択された更新種別から、次のリリース番号を算出します。major、minor、patch のいずれかを選ぶと、指定した要素を1つ増やし、それより下位の要素をすべてゼロに戻します。結果は新しい通常リリース系列を表すため、プレリリース識別子とビルドメタデータは削除されます。厳密な検証により、不正なバージョンや未対応の種別がリリーススクリプト、パッケージ公開、変更履歴、自動配信工程へ入る前に検出できます。

公開する変更内容に合う更新種別をお選びください

Semantic Versioning では3つのコア番号にそれぞれ異なる意味があるため、公開する変更の性質に応じて更新種別を決めます。major が増え、minor と patch はゼロに戻るため、4.8.6 は 5.0.0 になります。後方互換性を保ったまま機能を追加する場合は minor を選びます。

minor が増えて patch がゼロに戻り、4.8.6 は 4.9.0 になります。後方互換性のある不具合修正には patch を選び、同じ入力から 4.8.7 を得られます。この処理は意図的に機械的です。

ソースコード、コミット、変更履歴は調べず、変更が互換性を破るかどうかも判定しません。その分類はお客様のリリース方針で決定していただきます。

厳密な入力検証と接尾辞の削除をご確認ください

バージョンには Semantic Versioning 2.0.0 を厳密に適用し、major、minor、patch の全要素を指定する必要があります。有効な例は 1.2.3、2.0.0-rc.1、3.4.5+linux.x64 です。v1.2.3、1.2、コア番号の先頭にゼロがある形式などは自動修正せず拒否します。

プレリリース識別子とビルドメタデータも入力時に検証しますが、更新後の結果にはどちらの接尾辞も残しません。更新は新しいコアリリース番号を開始する操作です。2.1.0-beta.3 を patch 更新すると 2.1.1、minor 更新すると 2.2.0 になります。

古いリリース候補のラベルを新しい系列へ誤って引き継ぐことを防げます。

リリース自動化で決定的な計算をご利用ください

この計算機は、より大きなリリース工程に組み込める小さな決定的処理として設計されています。ネットワーク、時計、乱数、外部モデル、保存状態を利用しないので、同じ入力からは必ず同じ出力が得られます。数値要素は JavaScript の数値へ変換せず、10進数字の文字列として加算します。

そのため、安全な整数範囲を超える有効な要素でも丸め誤差なく正確に処理できます。単発の計画や確認にはブラウザー実行画面をご利用ください。

パッケージ公開をご準備ください

major、minor、patch の公開承認後に、マニフェストへ設定する次のバージョンを計算できます。

継続的デリバリーを制御できます

ラベルやコミット解析による分類を、後続工程で使える決定的なバージョンへ変換します。

各更新種別は何を変更しますか?

major は major を増やして minor と patch をゼロにします。minor は minor を増やして patch をゼロにし、patch は patch だけを増やします。

プレリリース識別子は残りますか?

いいえ。 有効な接尾辞は入力として受け付けますが、新しいコアバージョンからは削除します。

ビルドメタデータは結果に影響しますか?

いいえ。 有効性を確認したうえで、新しいバージョンの計算時に削除します。

先頭の v や patch の省略は使えますか?

いいえ。 3つのコア要素をすべて含む厳密な Semantic Versioning 2.0.0 文字列が必要です。

変更に必要な更新種別を判断してくれますか?

いいえ。コードやコミット、変更履歴の文章は読まず、互換性を壊す変更かどうかも判断できません。major・minor・patch はご自身やリリースの規則で選び、その後の計算は毎回同じ方法で行われます。

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

POSThttps://api.kit.forhosting.com/dev2/semver-bump

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

curl -X POST https://api.kit.forhosting.com/dev2/semver-bump \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"version":"2.7.4","bump_type":"minor"}'
{
  "version": "2.7.4",
  "bump_type": "minor"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.semver_bump",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

HTTPコード意味
401unauthorizedAPIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
402insufficient_balance残高が不足しています。チャージ後に再度お試しください。
404unknown_type指定されたタスクタイプは存在しません。タイプ名を確認してください。
429rate_limitedリクエストが多すぎます。しばらく待ってから再度お試しください。

公開する変更内容に合う更新種別をお選びください

公開 API に互換性のない変更が含まれる場合は major をお選びください。種別の決定後は常に一貫した計算を行うため、担当者、プルリクエストのラベル、コミット解析などが分類し、信頼できる最終計算を必要とする仕組みに適しています。

厳密な入力検証と接尾辞の削除をご確認ください

更新種別も小文字の major、minor、patch に限定され、それ以外は invalid_input になります。この厳密さにより、入力ミス、パッケージ管理ツール固有の省略形、不完全なバージョンを公開前に明確に停止でき、後から取り消しにくい誤ったタグの作成を防げます。

リリース自動化で決定的な計算をご利用ください

現在のバージョンと承認済みの種別を送り、返された bumped_version をマニフェスト更新、リリースブランチ、成果物名、リポジトリタグの候補などにお使いいただけます。応答には original_version と bump_type も含まれるため、依頼内容を再構成せずにログや承認画面を監査できます。ビルドサービス、CLI、継続的インテグレーションから自動実行する場合は、1件 $0.002 の API を呼び出し、invalid_input は公開前に修正すべきリリースデータの問題として扱ってください。

提案されたバージョンを検証できます

タグ作成や成果物公開の前に、計算結果とプルリクエストの提案値を比較できます。

不明な更新種別を指定するとどうなりますか?

invalid_input が返ります。major、minor、patch だけを指定できます。

API の料金はいくらですか?

API は1件 $0.002 です。対話的な確認にはブラウザー実行画面もご利用いただけます。

KITの完全なドキュメントを見る →