&tag(開発手法);
*目次 [#w89d7fa3]
#contents
*関連ページ [#meb6f01d]
*参考情報 [#fa7034f2]
*バージョン命名規則 [#a07f6e8e]
**セマンティックバージョニング [#n011cf8b]
-最近はセマンティックバージョニングというのが流行っている。[[セマンティック バージョニング 2.0.0:http://semver.org/lang/ja/]]
-セマンティックバージョンは以下の規則に従ってx.y.z的なバージョンをつけるというもの。
--APIの変更に互換性のない場合はメジャーバージョンを、
--後方互換性があり機能性を追加した場合はマイナーバージョンを、
--後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。
-ただしこれはライブラリ、フレームワーク、サーバーのようにAPIを提供するソフトウェアに適しているとされている。
**デスクトップアプリに適用できるか？ [#pb143827]
-[[release management - Semantic versioning for desktop applications - Programmers Stack Exchange:http://programmers.stackexchange.com/questions/200002/semantic-versioning-for-desktop-applications]]にて、デスクトップアプリで、セマンティックバージョニングが使えるかという話題が提供されている。
-使えないという意見がある一方、X.Y.Zを以下の方針で使っているというコメントもある。
-Z: バグフィックスのみを含むリリース。
-Y: UIのマイナーな変更、ユーザーに影響する新機能を追加したとき。
-X: UI/機能のメジャーアップデート(例。UI/レイアウトの大幅変更など)。
*git-flow vs github-flow [#g79ca7a3]
-gitのブランチをどのように使ってソフトウェアをリリースするかという話題。
-git-flowのほうが機能が豊富で、リリース間隔が1〜2週間に設定されているソフトウェア開発には向いているらしい(いわゆる普通のリリース)。
-だがあまりにも煩雑なので、[[Bakusoku Iterations Tokyoで話したりrebuild.fmで話したりしました - Islands in the byte stream:http://d.hatena.ne.jp/gfx/20140531/1401518237]]で使われているぐらいのブランチモデルを使いたい。
#ref(branch.png)
-この場合リリースはRCブランチから行われ、リリース後リリースブランチは削除される。サポートが必要な場合、リリースポイントからサポートブランチをさらに作ってメンテナンスするのだろうか？
-さらにGitLab flowというのもある。「Release branches with GitLab flow」というのがシンプルで分かりやすそう。各stableブランチへの修正は、Masterで変更したあとcherry-pickする。
*自作アプリのリリース [#y5c2fed0]
**Webアプリの場合 [#hcf28fea]
-GitBucketにバージョンごとにissueをまとめる。
-バージョンのissueにとりかかるまえ、ソフトバージョンを1.1.0のように設定。
-単独で導入できる機能が実装できた場合、1.1.0 beta 1 のようなベータ版としてできるだけ早期にリリース。1.1.0のissueを全て解決できた場合1.1.0正式版をリリースする。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
