前々からTracでチケットを登録する時の要素としてある「バージョン」って何に使うんだろうって思ってましたが、ソース管理上のバージョンのことだったのね・・・。
いや、そんなの当たり前と私も思うのですが、使うメリットがまったく見えていませんでした。
リポジトリブラウザも使っていないので、ソース管理とTracの連携を行わずに使っていたのでなかなか気づかず・・・。
で、具体的にどのように使うか（使ってみたか）というと、テストをする際のバグ出しにTracを活用してみたのですが、流れとしてはこんな感じです。
1. ソース管理上である時点までコミットされたものを、ステージング環境にアップします。
この時に、ソース管理上でバージョンタグを付与します。例えば「1.0」とします。
2. テスターにテストを開始してもらい、バグが発見された時点で、Tracにチケットを発行してもらいます。
この際に、テストしたステージング環境上のソースのバージョンをチケットのバージョン要素とイコールにしておきます。（これでチケットの要素のバージョンとソース管理上のバージョンがイコールになります）
3. ある一定の期間でテストを終了させ、それまでに上がったチケットに取り掛かりバグを修正していきます。
以後、この繰り返しで1.がくる度に、ソース管理上のバージョンを1つ繰り上げて登録（バージョン「2.0」が誕生）、それをステージング環境にまたあげなおし、そこで出たバグはそのバージョン（2.0）のチケットとして登録します。
こうする事で、それがどのバージョンのソースの時に出たバグなのかがぱっと分かります。
※ ソース管理上であまり細かくバージョンを付与しておくと、Tracにもそのバージョンを増やさないといけなくなるので結構
手間になります。
ですので、「1.0」「2.0」「3.0」などとかなりざっくりとバージョンをきってしまった方が管理しやすいと思います。
本番リリース後のバージョンの使い方も同様です。
現在本番環境で稼動しているソースのバージョンとそこで出た不具合や要望、課題などのチケットを登録する際にそれがどのリリースバージョンで上がってきたものなのかが分かりやすくなります。
リリース後も、開発が進んでいくことはよくある事なので、ソースのバージョンとチケットの関連性をうまく紐付け
しておけば、何時の頃から出ているバグなのか、それが今後の開発の中で取り込まれていく（いった）のかが分かりやすく整理できます。
Tracを本来のバグ管理（BTS）システムとしてではなく、タスク管理システムのように使っていたので、ちょっと目からうろこでした。
関連記事
Tracの使い方 - trac-adminの使い方、チケットの管理とロードマップの確認 -
Tracの使い方 －Timing and Estimationプラグイン－
Trac ： T&Eプラグインを利用した、期間を限定したレポートの作り方
Tracの使い方 - Trac上で管理されている権限一覧 -
Tracの使い方 - バグ管理システム以外のTracの用途 -