&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ブランチから行われ、リリース後リリースブランチは削除される。サポートが必要な場合、リリースポイントからサポートブランチをさらに作ってメンテナンスするのだろうか? *自作アプリのリリース [#y5c2fed0] **Webアプリの場合 [#hcf28fea] -GitBucketにバージョンごとにissueをまとめる。 -バージョンのissueにとりかかるまえ、ソフトバージョンを1.1.0のように設定。 -単独で導入できる機能が実装できた場合、1.1.0 beta 1 のようなベータ版としてできるだけ早期にリリース。1.1.0のissueを全て解決できた場合1.1.0正式版をリリースする。