色々と困った事になっているようですね。

私もOutlook→Windows Live Mailを経てThunderbirdにメーラーを乗り換えてずいぶん経ちますが、Thunderbirdの場合はFirefoxと比較して新機能の為に「高速リリースサイクル」にするというメリットが余り見いだせませんし、むしろ[u]メールボックスやアドレス帳などかなり多くのデータを保持している[/u]為に（SeaMonkeyのメール機能も同様の事が言えますが）、新しいメジャーバージョンに存在するバグによって受けるダメージが（自動更新も相まって）どうしても大きくなりがちに感じます。
個人的な意見ですが、ある程度まとまった（プライベートな）データを取り扱う以上、メーラー[b]に求められるのは新機能よりも安定性・信頼性であるはず[/b]です。データが消えたり壊れたりする可能性が常につきまとうメジャーバージョンアップが頻繁に行われ、それが自動更新によってユーザが知らないうちに行われるのでは、今までのように安心して利用する事が出来なくなります。それなのに、（Firefoxだけでなく）なぜThunderbirdにまで「高速リリースサイクル」を適用したのか？と、未だに思う事があります。

そもそも私自身、Firefox 5.0が出ると同時に4.0系列を[b]事前予告なし[/b]で事実上サポートを打ち切り<>（4月末にサポート終了した3.5系列等から4.0系列に移ってきた全てのユーザに、脆弱性をネタにして「高速リリースサイクル」のバージョンへの移行を強要するような対応に見える）、更に追い打ちをかけるようにMozillaの主要人物があのような問題発言をした事<参考：http://internet.watch.impress.co.jp/docs/news/20110720_461740.html>もあって、（それがMozillaの総意ではないとしても）今のMozillaは[b]本当に全ての利用者を大切にしていると言えるのか[/b]と、ユーザの一人として疑念を抱いている次第です。
「高速リリースサイクル」に移行する理由として「Webの進化するスピードに追従してゆく為」「セキュリティ修正を含むアップデートを分かり易くする為」といった事が掲げられていますが、そこまで短いリリース間隔、つまり6週間隔（年8～9回Major Ver. UP）である必要が本当にあったのか、この間隔にした本当の理由はGoogle Chromeの二番煎じ...もとい急激に増えていくバージョン番号に対抗する為ではないか、といった裏の思惑をどうしても勘ぐりたくなってしまうのは自分だけでしょうか？
Google Chromeのように最初から一貫して「最新技術をどんどん取り込む事を優先して6週間隔でMajor Ver. UP、最新安定版のみサポート」というポリシーで開発されているアプリケーションならばともかく、そうでないポリシーの基にこれまで開発されていたものを突然このような開発・サポート体制にして、本当に従来と同等以上のソフトウェア品質を維持できるのか（品質管理に使えるリソースがテスト期間に見合ったものでなければ品質低下のリスクが増大する）、と思っていたら案の定、

・Firefox/Thunderbird 7.0・SeaMonkey 2.4への更新後に一部アドオンが消える問題<参考：http://internet.watch.impress.co.jp/docs/news/20110929_480425.html>（実は8月21日時点でBugzillaに報告があった<参考：https://bugzilla.mozilla.org/show_bug.cgi?id=680802>にも関わらず放置されていたらしい）
・Firefoxが約9分毎にフリーズ<参考：http://journal.mycom.co.jp/news/2011/10/05/011/index.html>（5.0の時点で存在していたらしい）

これらの事例からは、「高速リリースサイクル」によって必ずしもバグの修正が迅速になるとは限らず、むしろシステムの多様性もあって品質管理部門へのしわ寄せが大きくなる事を示しているようです。

それに、元々異なる方向性で作られていたFirefox・ThunderbirdとGoogle Chromeでは当然利用者が求めるものは違うわけですし、[b]一般のFirefox・ThunderbirdユーザがGoogle Chromeのようなやり方を求めているとは一概には言えない[/b]と思います。それどころか、下手をすれば一部の人間の自己満足の為にMozillaのブランドイメージを傷つけてしまうかもしれないと危惧しています。

そして何より、バージョンアップによってそれまで利用できていたWebサービスに問題が起きる可能性は本当にあり得ないと言い切れるのか、といった懸念があります。
いくらインターネットの進化が早いと云ってもここまで短いサイクルで進化しているわけではないはずで、このままMozillaがGoogle Chromeに張り合うような形でMajor Ver. UPを繰り返していけば、むしろサービスを提供する側がそれについていけなくなって新しいバージョンや別のブラウザで利用できないサイトが増えていき、やがてインターネットの方がブラウザの進化について行けなくなった挙げ句、[u]ブラウザが究極の進化＝自滅を迎えるという最悪のシナリオ[/u]もあり得ます。

今一度、Mozillaの上層部の方々には初心に帰って、誰の為のFirefox・Thunderbirdなのか、誰の為のGecko（と関連技術）なのか、誰の為のMozillaブランドなのか、そして何より[b]誰の為のインターネットなのか[/b]をよく考えて、開発体制の見直しも視野にきちんと検討して頂きたいなと想う、今日この頃です。

[quote="Cai"]こーやって並べてみるとカオスですねー [/quote]
日常的には個々の "木" だけを見慣れていますが、あらためて "森" を見ると深い闇さえ見えてくる気がします（笑）。
森の中の曲がりくねった細い道をたどってゆくと老若の狐や猿や鳥がうごめく混沌とした世界が......。

[quote="Cai"]LTS 版も最後の一桁使って維持するんじゃないでしょうか？
42 か月サポートでイニシャルリリース+7 リリース = x.0.7 で打ち止めですし[/quote]
https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal
にあるスケジュール案で、Extended Support Release (ESR) 版のバージョン表記を
8.1.1 、8.1.2 、8.1.3 …… のように
V.m.r で浮いている m 部を 1 にすれば、ノーマルリリース版と ESR 版を区別しやすいかなと思ったんですけどね。
m 部が 0 ならノーマル、1 なら ESR って......。

ついに二桁が視界に…
[quote="偶然的通行人"]その関係でひとつ疑問があります。
従来のバージョン表記は、
2.0.20 、3.0.19 、3.5.19 、3.6.23 ……
のような V.m.r の形式でした。
このときは V 部と m 部の区別があいまいだったとは思うのですが、高速リリースサイクルに入ってからの m 部はどのような意味を持っているのでしょうか？
　　｜ 6.0.2 とか 7.0.1 のように微細だが緊急の修正の場合、
　　｜ r 部分の変更が順当だとは思うのですが。

4.0 、5.0 、6.0 、7.0 、8.0 …… のような V 部増加のパターンではなく、
4.1 、4.2 、4.3 、4.4 、4.5 …… のような m 部増加のパターンもありえたと思ます（SeaMonkey がそうですね）。

まあ、V 部で数を増やしたほうが進捗感が増しますし、なんとなくお得なイメージはあるんですけど、m 部を留保しているってことは何か将来的な "含み" でもあるのでしょうか？　LTS 版用に使えそうな感じもしますし...。それとも単にバージョン表記の互換的な措置？？[/quote]
[code]Gecko : Fx - Tb - Sm - Cm
1.7.0.y : 1.0.x - 1.0.x -
1.8.0.y : 1.5.0.x - 1.5.0.x - 1.0.x - 1.0.x
1.8.1.y : 2.0.0.x - 2.0.0.x - 1.1.x - 1.5.x, 1.6.x
1.9.0.y : 3.0.x - - - 2.0.x
1.9.1.y : 3.5.x - 3.0.x - 2.0.x -
1.9.2.y : 3.6.x - 3.1.x - - 2.1b
2.0.y : 4.0.x - (3.3a) - 2.1.x -
5.0.y : 5.0.x - 5.0.x - 2.2.x -
6.0.y : 6.0.x - 6.0.x - 2.3.x -
7.0.y : 7.0.x - 7.0.x - 2.4.x -[/code]
こーやって並べてみるとカオスですねー :shock:
LTS 版も最後の一桁使って維持するんじゃないでしょうか？
42 か月サポートでイニシャルリリース+7 リリース = x.0.7 で打ち止めですし

二桁が現実になってきましたねえ。
なんか高齢化が進んでいるようなイメージもあるんですが...。

その関係でひとつ疑問があります。
従来のバージョン表記は、
2.0.20 、3.0.19 、3.5.19 、3.6.23 ……
のような V.m.r の形式でした。
このときは V 部と m 部の区別があいまいだったとは思うのですが、高速リリースサイクルに入ってからの m 部はどのような意味を持っているのでしょうか？
　　｜ 6.0.2 とか 7.0.1 のように微細だが緊急の修正の場合、
　　｜ r 部分の変更が順当だとは思うのですが。

4.0 、5.0 、6.0 、7.0 、8.0 …… のような V 部増加のパターンではなく、
4.1 、4.2 、4.3 、4.4 、4.5 …… のような m 部増加のパターンもありえたと思ます（SeaMonkey がそうですね）。

まあ、V 部で数を増やしたほうが進捗感が増しますし、なんとなくお得なイメージはあるんですけど、m 部を留保しているってことは何か将来的な "含み" でもあるのでしょうか？　LTS 版用に使えそうな感じもしますし...。それとも単にバージョン表記の互換的な措置？？

正式版では無いがNightlyで二桁突入しちゃいました・・・
10.0a1・・・（汗

[url=http://japan.cnet.com/news/service/35006518/]モジラ会長、「Firefox」の高速リリースサイクルを語る[/url] の記事（とリンク先）を見る限りでは、高速リリースサイクルにともない起こりうるいくつかの問題点を認識されているようですが、デメリットよりはメリットを優先して「高速リリースサイクル」（Rapid Release Process）の路線で行くってことみたいですね。

[quote="Cai"]こういうことらしいので、LTS 候補になりうるのは 3.6 系が最初で最後ですね。[/quote]
開発リソースに限りがある中で、あれもこれもは無理があるでしょうからねえ。（Firefox については全体的な方向性がモバイル版のほうにシフトしているみたいですし...。）
[size=100]　　｜ でも 3.6 系は、現役で稼動している低スペックなマシンでも
　　｜ 4.0 系以降と比べればそこそこ安定的に動いてくれるので、
　　｜ LTS 版になってくれると助かる人は多いかも。[/size]

[quote="Cai"]# 2 桁番号とか違和感ありすぎる…[/quote][quote="aides"]二桁は考えたくは無いですね。[/quote]
ご存知と思いますが、バージョンナンバーについては、ここんとこ下記のような動きがあったようです。
・[url=http://slashdot.jp/it/11/08/17/0754210.shtml]Firefoxからバージョンナンバーが消えるかも[/url] （とリンク先）
・[url=http://journal.mycom.co.jp/news/2011/08/29/007/index.html]Firefox、バージョン番号据え置きへ - 騒動は勘違いが原因!?[/url]
マイコミジャーナルの記事にあるような副産物が、よい方向に作用してくれることを期待したいです。

…な～んてことに気をもんでいても仕方ないですかね（笑）。
追っかけて身動きとれなくなって "拘束リリースサイクル" に陥るぐらいなら、自分にとって "安全な速度" でゆったり運用していこうと思います。
[size=100]　　｜ もともとたいしたスキルはなく、ますます進歩についていけなくなりそうなので、
　　｜ このフォーラムへのぼくの書き込みも自然に減っていくかもしれません。[/size]
　

二桁は考えたくは無いですね。
以前なら*.*.##と末尾に付与されるのが当たり前でしたが、現状からは「##.*.*」にも為りかねない状況です。
恐ろしい（汗

Mozilla 的には

http://weblogs.mozillazine.org/asa/archives/2011/08/every_six_weeks.html
[code]+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
| August 16th | September 27 | November 8 | December 20 | January 31 | March 13 | April 24 | June 5 |
+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+
| Firefox 9 on m-c | Firefox 10 on m-c | Firefox 11 on m-c | Firefox 12 on m-c | Firefox 13 on m-c | Firefox 14 on m-c | Firefox 15 on m-c | Firefox 16 on m-c |
| Firefox 8 on Aurora | Firefox 9 on Aurora | Firefox 10 on Aurora | Firefox 11 on Aurora | Firefox 12 on Aurora | Firefox 13 on Aurora | Firefox 14 on Aurora | Firefox 15 on Aurora |
| Firefox 7 on Beta | Firefox 8 on Beta | Firefox 9 on Beta | Firefox 10 on Beta | Firefox 11 on Beta | Firefox 12 on Beta | Firefox 13 on Beta | Firefox 14 on Beta |
| Firefox 6 in Release | Firefox 7 in Release | Firefox 8 in Release | Firefox 9 on Release | Firefox 10 on Release | Firefox 11 on Release | Firefox 12 on Release | Firefox 13 on Release |
+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+[/code]
こういうことらしいので、LTS 候補になりうるのは 3.6 系が最初で最後ですね。

# 2 桁番号とか違和感ありすぎる…

aides さん、Cai さん、レスありがとうございます。

開発現場がどうなっているのかも気にはなりますが、会社や学校など組織のシステム管理者といった全体のメンテナンスとケア、サポートを担うような立場の人たちが、一番振り回されるのかな、と......。

自動更新任せで使用中のバージョンへの関心も持たないような一般のエンドユーザーにとっては、従来スタイルだろうが「高速リリースサイクル」だろうが、それほど大きな差は感じないのかもしれません。

個人的には、
http://mozilla.jp/blog/entry/7024/
http://mozilla.jp/blog/entry/7131/
――にあるように、3.6 系の「法人ユーザワーキンググループ」の議論がどうなるかも関心はあります。
3.6 系に限らず、LTS 版（＝長期サポート版　≒安定稼動版）が実現できるなら、それはそれでユーザーの選択肢が増えてありがたいですし。

[quote="Cai"]多チャンネル化してからは beta (のリリース版)しか追っかけてません[/quote]
ですよね～。
ぼくも重点的にはそうしているんですが、Aurora や Nightly の情報に接するとつい手を出してしまい、墓穴を掘っています。（苦笑）

[quote="偶然的通行人"]例えば、このフォーラムでも "これが原因では？" と思われる質問が寄せられていますが、Firefox 5.0 から 6.0 でコネクション関係の初期設定値が大幅に変更されているものがあります。
network.http.max-connections
の初期値が 256 ってどうなんでしょう？
もちろん、クライアント側のシステムスペックやネットワークの条件、接続するサーバ側の条件などが関係してくるので短絡的に是非を問えないとは思うのですが、ユーザーの利用環境によっては動作不良を起こすケースがあるんじゃないでしょうか？
（少し前までは、30 の初期値でも大きいので 16 - 24 程度に下げることなどがあちこちで指摘されておりましたし...。）

ほかにもこういったケースはありますし、Thunderbird にも通じることではあります。
Mozilla の運営陣がどのようなユーザー層に焦点を当てているかよくわかりませんが、Firefox / Thunderbird を快適に使おうと思えば、それなりの（恵まれた）環境条件が必要ってことなんでしょうかねえ。[/quote]
Mozilla の設計思想が超富豪向け (メモリもストレージも CPU も) なのは今に始まったことではないですが :P
network.http.max-connections の初期値が 256 ってのはやりすぎですよねぇ…
# 30 になった時も一悶着あった覚えが

[quote="偶然的通行人"]まあ、ただの弱音なんですが、もう素人の余技の範疇で Firefox / Thunderbird の次期バージョンを追っかけるのは（＝事前に仕様を把握したりテストするなどは）、この先キツイかもしれません。[/quote]
多チャンネル化してからは beta (のリリース版)しか追っかけてません :?

少し前はメジャーアップデートは数ヶ月に一回程度なのが、5.0からは6週間周期と変更されたのは、色々な確認作業をする上でも短いですね。
コレを「由」とするか、しないかの問題は非常に難しい問題です。
バグの問題では先日adobe flashがクラッシュすると云う不具合がNightlyで発生し、一日で修正されましたが、こう云った迅速な対応は有難いのですが、こうも高速リリースする本当の意義が見い出せないのが正直な処です。

雑談で失礼します。

早くも「高速リリースサイクル」についていけなくなっています（苦笑）。
どんどん新機能が実装され、それを即座に体験できることや、バグ修正の反映が早くなるのは、エンドユーザーにとっても大きなメリットなんですが、それらの仕様の把握や修正結果をじっくりテストできないまま最新版がリリースされ、更新の結果として常用環境でいきなり問題が起こるようなケースへの対処が、つい後手にまわりがちになっています。

自分は、家族・友人・仕事仲間など身の回りのユーザーのサポート役のような立ち位置にいるのですが、専門的なシステム管理者ではなく、本業（思いっきり非 IT 分野）の合間にベータ版のテストや仕様変更の確認などをやっているに過ぎない素人のため、従来でもなかなか手が回らなかったところ、現在はすでに息が上がりはじめています（嘆）。

背景にはユーザーの利用環境の多様性があるのは確実で、Firefox を 4.0 -> 5.0 -> 6.0 と普通にアップグレードしても問題が起こるユーザーと起こらないユーザーがいて、それ自体は従来と大差はないのですが、これが短サイクルでくり返されるため、こちらの情報収集や対策が追いつかない感じです。

例えば、このフォーラムでも "これが原因では？" と思われる質問が寄せられていますが、Firefox 5.0 から 6.0 でコネクション関係の初期設定値が大幅に変更されているものがあります。
network.http.max-connections
の初期値が 256 ってどうなんでしょう？
もちろん、クライアント側のシステムスペックやネットワークの条件、接続するサーバ側の条件などが関係してくるので短絡的に是非を問えないとは思うのですが、ユーザーの利用環境によっては動作不良を起こすケースがあるんじゃないでしょうか？
（少し前までは、30 の初期値でも大きいので 16 - 24 程度に下げることなどがあちこちで指摘されておりましたし...。）

ほかにもこういったケースはありますし、Thunderbird にも通じることではあります。
Mozilla の運営陣がどのようなユーザー層に焦点を当てているかよくわかりませんが、Firefox / Thunderbird を快適に使おうと思えば、それなりの（恵まれた）環境条件が必要ってことなんでしょうかねえ。

まあ、ただの弱音なんですが、もう素人の余技の範疇で Firefox / Thunderbird の次期バージョンを追っかけるのは（＝事前に仕様を把握したりテストするなどは）、この先キツイかもしれません。

（参考）[b]Firefox の about:config にリストアップされるコネクション関係の設定項目と初期値[/b]
設定名↓／Firefox のバージョン→ [color=white]_____________________[/color] 3.6 [color=white]___[/color] 5.0 [color=white]____[/color] 6.0 [color=white]___[/color] 7.0b
dom.server-events.default-reconnection-time　[color=white]_________[/color] 　X [color=white]___[/color] 　X [color=white]___[/color] 5000 [color=white]___[/color] 5000
network.ftp.idleConnectionTimeout　[color=white]___________________[/color] 300 [color=white]___[/color] 300 [color=white]___[/color]　300 [color=white]___[/color]　300
network.http.connection-retry-timeout　[color=white]_______________[/color] 　X [color=white]___[/color] 　X [color=white]___[/color]　250 [color=white]___[/color]　250
network.http.max-connections　[color=white]________________________[/color]　30 [color=white]___[/color]　30 [color=white]___[/color]　256 [color=white]___[/color]　256
network.http.max-connections-per-server　[color=white]_____________[/color]　15 [color=white]___[/color]　15 [color=white]___[/color] 　15 [color=white]___[/color] 　15
network.http.max-persistent-connections-per-proxy　[color=white]___[/color] 　8 [color=white]___[/color] 　8 [color=white]___[/color]　　8 [color=white]___[/color]　　8
network.http.max-persistent-connections-per-server　[color=white]__[/color] 　6 [color=white]___[/color] 　6 [color=white]___[/color]　　6 [color=white]___[/color]　　6
network.websocket.max-connections　[color=white]___________________[/color] 　X [color=white]___[/color] 　X [color=white]___[/color]　　X [color=white]___[/color]　200
（注）
　・X＝設定項目自体が存在しない。
　・上記一覧は等幅フォント表示でズレずに最適化されます。