開発手法 にそのファイルは見つかりません

&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ブランチから行われ、リリース後リリースブランチは削除される。サポートが必要な場合、リリースポイントからサポートブランチをさらに作ってメンテナンスするのだろうか？

• さらにGitLab flowというのもある。「Release branches with GitLab flow」というのがシンプルで分かりやすそう。各stableブランチへの修正は、Masterで変更したあとcherry-pickする。

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

Webアプリの場合†[edit]

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

Contents

メニュー

• about
• blog
• blog(はてな)

配布物

• FaEdit
  • ヘルプ
  • BugTrack
• WikiHelpMaker
  • ヘルプ
  • BugTrack

ゲーム

• 時のオカリナ3DS
• ドラゴンズドグマ
• スプラトゥーン2
• DQB2
• ジョイコン

ショートカット

• 用語集A-Z
• 用語集ア-ワ

最新の20件