Tag: 開発手法

目次

関連ページ

参考情報

バージョン命名規則

セマンティックバージョニング

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

デスクトップアプリに適用できるか?

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

git-flow vs github-flow

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

自作アプリのリリース

Webアプリの場合

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

添付ファイル: filebranch.png 376件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2016-04-13 (水) 16:48:34