議論/CVSブランチ

CVSのブランチの切り方について †

• 今後の開発を進めるにあたり、CVSブランチを切るかどうか、切るならどう切るかを議論。
• 案のある人は、どんどん書き込みよろしくお願いします。
• ひげぽんさんの気に入った案が出た時点で議論終了となります（ｗ

こんなことが議論されるとうれしい ひげぽん †

• ユーザーアプリ作者への安定開発版提供時のブランチ・タグの方針
• 一般ユーザ向けのリリース時のブランチ・タグの方針
• 最新開発不安定版の取り扱いについて

ブランチ †

• 2段構成
  • MAIN
  • HEAD

案 †

ブランチ利用ポリシ †

• MAIN
  • Kernel、OSサーバのバグfix
    • HEADからたまにソースマージ
  • Apps開発
• HEAD
  • Kernel、OSサーバをがんがん開発(機能追加とか)

• こんな感じ？ -- shadow

タグ命名規則 †

• タグ案1 -- shadow 2004-03-12

  <type><ver>-<reason>
  type : r(=release) s(=stable) c(=current)
  ver : version番号
  reason : 理由　or 現在の状態

• 例

  r0_1_5
  s0_1_6-merge_scheduler
  c0_1_7-branch_point

コメント †

• Mozillaを意識したのかもしれないけどちょっと違うと思う。基本的にcurrentは他人のことなんか考えない。壊れ放題。nightlyはcurrentから自動的にビルドされたもので、ブランチではない。ユーザーアプリ製作者はCVSに手を出さずにリリース版だけ対象にさせるべきでは。 -- 2004-03-09 (火) 13:03:41
  • 案1は、廃案にしました。　-- shadow
• やっぱ、センスや経験のある人じゃないといい案が出せませんね。 -- shadow 2004-03-09 (火) 23:53:52
• ここはCVSとオープンソースPJに関わったことのある人の意見が聞いてみたいですね。 -- ひげぽん 2004-03-09 (火) 23:55:00
• CVSに詳しいといえばhenohenoさんとか。 -- ひげぽん 2004-03-09 (火) 23:55:50
• ３つ名前付けるんなら release, stable, current かなぁ？それで release は v0.1.5 とかと同じ感じ。開発者用は stable と current だけで良いかな。とか。 -- Gaku 2004-03-10 (水) 00:02:53
• 一番の問題は、stableブランチ、releaseブランチをメンテする人がいないから、タグで十分なことですかね。 -- shadow 2004-03-10 (水) 09:09:34
• とりあえず、しばらくは、タグのみの運用でよさそうですね。OSサーバを作りこむようになってきたら、また考えましょう。 -- shadow 2004-03-11 (木) 00:57:18
• そうですね。タグの命名規則決めましょうか?shadowさんにもTAG付けしていただきたいですし。 -- ひげぽん 2004-03-11 (木) 01:00:52
• 案2、3廃止。4作成。 -- shadow 2004-03-11 (木) 13:30:51
• レイアウト変更。タグ案追加。 -- shadow 2004-03-12 (金) 01:40:03
• Tinoさん何かご意見ありますでしょうか? -- ひげぽん 2004-03-12 (金) 23:41:45
• あとは、まかせた（ぇ -- shadow 2004-04-11 (日) 17:58:18

廃案 †

• 過去の残骸、邪魔なので下に持ってきた。-- shadow 2004-03-12

案1 -- shadow 2004-03-09

• stable : 一般ユーザ向けリリース用の最新
• current : ユーザアプリ開発者向けリリース用の最新 ユーザアプリが(何とかｗ)動作可能
• nightly : 最先端開発版　コンパイルが可能

• 運用方針
  • 動かないかもしれないけどがんがんコードを書くときは、currentの最新からnightlyを作成する。
  • nightly版がcurrent相当の条件を満たせばcurrentにマージする。
  • current版がstable相当の条件を満たせばstableに反映してリリースする。

案2 -- shadow 2004-03-09

• stable : 一般ユーザ、ユーザアプリ開発者向けのリリース用の最新
• current : OSサーバ開発者向けの最新 ユーザプロセスが(何とかｗ)動作可能
• experimental : 実験版　コンパイルが可能

• 運用方針
  • MAINブランチで一般向けリリース時にstable版のタグ付けをする。(今までどおり)
  • MAINブランチのHAEDがcurrent版あつかい(今までどおり)
  • experimentalブランチを切る。何とか動作するようになったらMAINにマージ。
• 問題点
  • 案1とたいして変わってない。

案3 -- shadow 2004-03-09

• MAINブランチ(今までどおり)
• 各自ブランチ : 実験的なコードを書く人が自分で実験用ブランチを切る。

• 運用方針
  • 実験的コードを書く人以外からは、ほぼ今までどおりにみえる。
• 問題点
  • CVSの利点がいきてない?

案4 -- shadow -2004-03-11

• Stableブランチ : 安定版
• Currentブランチ : 最新開発不安定版

• 運用方針
  • Currentブランチに対する修正はなんでもあり。修正前に、連絡帳などで宣言した方がいいかな？
  1. 該当部を修正してCommitする。
  2. 該当部の管理者(メインでコードを書いている人。ほぼ、ひげぽんさんかなｗ)に通知する。連絡帳か、今日の一言か、専用ページ(を作る)で通知でいいかな?
  3. 管理者は、修正が妥当だと思ったら該当部をstableブランチにマージする。
  • 修正者と管理者が同じと言う場合もある。
    • Current使わず、直でStableにCommitもOK。でも、面倒でもCurrent使った方が安全かも。
  • Release版は、Stableブランチにタグ付け。Releaseに対する修正はなし。
• 将来
  • Release版に対する修正を行うようになったらreleaseブランチを作る。
  • Currentに対するexperimental(仮)を作る。
    • 影響の大きな設計変更をする場合(メッセージ授受変更など動かなくなる可能性が大きい場合)、実験目的に使う。

• 問題点
  • current荒れ放題（ｗ。これが普通のCVSの使い方なのかな？

MENU

• はじめに
• スクリーンショット
• ドキュメント
• ダウンロード
• スペック
• プロジェクトマップ
• BayGUI(ADK)
• MonAPI
• Mona(0.4.0)
• 質問所(パッチ)
• デバッグ技法
• コミュニティ
• 連絡帳
• 議論
• 提案
• ご意見箱
• スレッド(現行)
• Reading作業ログ

リンク

• ひげぽんはてなダイアリー
• Higepon blog(英語)
• 和製OS情報

最新の20件

最新の20件