開発手法 の履歴(No.2)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 開発手法 へ行く。
  • 1 (2015-10-30 (金) 12:57:04)
  • 2 (2015-10-30 (金) 13:11:03)

&tag(開発手法);

目次†[edit]

関連ページ†[edit]

参考情報†[edit]

バージョン命名規則†[edit]

セマンティックバージョニング†[edit]

• 最近はセマンティックバージョニングというのが流行っている。セマンティック バージョニング 2.0.0
• セマンティックバージョンは以下の規則に従ってx.y.z的なバージョンをつけるというもの。
  • APIの変更に互換性のない場合はメジャーバージョンを、
  • 後方互換性があり機能性を追加した場合はマイナーバージョンを、
  • 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。
• ただしこれはライブラリ、フレームワーク、サーバーのようにAPIを提供するソフトウェアに適しているとされている。

デスクトップアプリに適用できるか？†[edit]

• release management - Semantic versioning for desktop applications - Programmers Stack Exchangeにて、デスクトップアプリで、セマンティックバージョニングが使えるかという話題が提供されている。
• 使えないという意見がある一方、X.Y.Zを以下の方針で使っているというコメントもある。
• Z: バグフィックスのみを含むリリース。
• Y: UIのマイナーな変更、ユーザーに影響する新機能を追加したとき。
• X: UI/機能のメジャーアップデート(例。UI/レイアウトの大幅変更など)。

git-flow vs github-flow†[edit]

• gitのブランチをどのように使ってソフトウェアをリリースするかという話題。
• git-flowのほうが機能が豊富で、リリース間隔が1〜2週間に設定されているソフトウェア開発には向いているらしい(いわゆる普通のリリース)。
• だがあまりにも煩雑なので、Bakusoku Iterations Tokyoで話したりrebuild.fmで話したりしました - Islands in the byte streamで使われているぐらいのブランチモデルを使いたい。
  
• この場合リリースはRCブランチから行われ、リリース後リリースブランチは削除される。サポートが必要な場合、リリースポイントからサポートブランチをさらに作ってメンテナンスするのだろうか？

自作アプリのリリース†[edit]

Webアプリの場合†[edit]

• GitBucketにバージョンごとにissueをまとめる。
• バージョンのissueにとりかかるまえ、ソフトバージョンを1.1.0のように設定。
• 単独で導入できる機能が実装できた場合、1.1.0 beta 1 のようなベータ版としてできるだけ早期にリリース。1.1.0のissueを全て解決できた場合1.1.0正式版をリリースする。