リリース管理サイクルでバージョン番号を増やす場合

Question

GitHub、TeamCity、CodeReviews、Octopus deployの組み合わせを使用して、全体のリリース管理プロセスを管理します。私たちはウェブサイトといくつかの内部的に使用されるAPIを開発しています。

私たちは、特に私たちのAPIのより良いバージョン管理を実装しようとしており、Semverを使用します。

私の質問は、どの段階にバージョン番号を割り当てていますか？

例：

• マスターの現在のバージョンは1.2.1
• ユーザーは、ブランチを作成している（支社）いくつかの新しい機能を実装する
• ユーザーは、レビューのためにQAに支社を展開し、サインオフ
• ユーザーはBranch2をMasterにマージし、Productionにリリースします。

どの段階でバージョンを1.3.0に増やす必要がありますか？それがQAに入る段階で更新されると、その間に別の開発者がBranch2よりはるかに早くProductionにリリースするためにテストされ、準備が整った別の機能ブランチを作成する可能性があります。 0になりますが、後でProduction WeekにプッシュされるBranch2は[1.4.0になっているはずです。

QAがサインオフされ、マスターブランチに最終的にマージされる前に、バージョン番号を増分する必要があると思いますか？事前にお時間を

おかげ よろしく、 dotdev

Answer 1

あなたは私がこれらのバージョンご覧説明したよう：マスターで

• 1.2.1現在のバージョンを1.2.1
• 1.3.0-alpha+branch2ユーザーは、ブランチを作成しています（ Branch2）を使用して新しい機能を実装する
• 1.3.0-beta+branch2ユーザーがBranchAをQAに配置してレビューとサインオフを行う
• 1.3.0ユーザーがBranch2をMasterにマージし、Productionにリリースします。

は、公式/プロダクションリリースの直後ににする必要があります。ここに役立つスケッチがあります。

feature       *-(1.3.0-beta+feature1)---*       *-(1.4.0-beta+feature2)-- 
           /       \      /
master -[v1.2.1]-(1.3.0-beta)-*-----------------------------*-[v1.3.0]-(1.4.0-beta)--*----- 
      \              \  
release  *----             *--- 

は手動版（通常括弧）は歴史の中で、アカウントタグを取り込みながら、角括弧で表さ公式リリースにタグを適用します。

計算の管理に役立つ素晴らしいGitVersionツールをご覧ください。