アカウント名:
パスワード:
素人考えかもしれませんが、1.5 と指定してあったら、1.5.*.* と解釈するのが妥当だと思うのですが。
いい線だとは思います。
1.5と完全に互換性を有する (ということにされている) ものが、今回の1.5.0.x系列です。で、万が一互換性を維持しきれない (APIの変更を必要とする) 修正が必要だった場合に備えて、1.5.x.x系列が用意されています。この2種類の修正版の系列を用意したのは、Firefox 1.0.5でAPIの変更が行われ問題が多数発生した為1.0.6を要した経験 [slashdot.jp]に基づいています。
明言はされていませんが、例えば 1.5→1.5.0.1→1.5.0.2→(API変更)→1.5.1→1.5.1.1 みたいな感じでリリースされるのではないかと思っています。…判り辛いですね。判り辛いが故に何度か告知されている (Mozilla Developer News » Blog Archive » Extension Versioning in Firefox and Thunderbird 1.5 [mozilla.org], Mozilla Developer News » Blog Archive » Firefox Extension Versioning [mozilla.org]) んですが。
とはいえもっとスマートな方法は無かったのか、とは最初にバージョン付けルールが公開された時に私も思いましたけど。
自作の拡張の寿命をあらかじめ設定しておかなければならないこと。 将来どのバージョンで動かなくなるかなんて分かるわけがない。
いえ、「寿命」ではなく、現行の最新バージョンを指定すべしというのが、最高バージョン番号設定の基本的なルールになっています。 最新リリース版の番号より新たなものを設定してはならない、という記述がExtension Versioning [mozilla.org]のChoosing minVersion and maxVersion節にあります (既にこの原則は崩れているようですが)。
で、新バージョンがリリースされたら (リリース候補の時点で?)、製作者が互換性を確認し、更新マニフェストファイルを書き換えます。本体の更新時、或いは拡張マネージャで対応版の存在の確認をすると、更新マニフェストファイルを解析して、最高バージョン番号を書き換えます。
つまり、予め寿命を指定するのではなく、(アプリケーション) 本体のバージョンアップ毎にリモートのデータソースを書き換えろ、というのがFirefoxの拡張マネージャの設計です。更新時にプラグインパッケージの読み込みが不要になっていることに注意して下さい (Bug 251473 [mozilla.org])。ちなみにデータソースの量は1kB/拡張・テーマ、程度です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
0.0.0.1を巡る馬鹿騒ぎ (スコア:2, 興味深い)
ユーザーの評価も落ちるし拡張作者の負担にもなる。
こんなわけのわからないルールは他に見たことないよ。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:1, 参考になる)
本当にメンテナンスリリースの0.0.0.1アップでも動かなくなる拡張だったら仕方ありませんけどそんなの滅多にないし
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:1, 興味深い)
それならなおさら、ユーザーに余計な負担をかけてまで、maxVersion に 1.5 を指定している拡張を無効化する必要はないですね。
私は拡張を利用するだけの立場ですが、対応バージョンを指定するときに 1.5 ではなく、わざわざ 1.5.0.* と指定しなくてはならないのには何か理由があるのでしょうか?
素人考えかもしれませんが、1.5 と指定してあったら、1.5.*.* と解釈するのが妥当だと思うのですが。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:4, 参考になる)
いい線だとは思います。
1.5と完全に互換性を有する (ということにされている) ものが、今回の1.5.0.x系列です。で、万が一互換性を維持しきれない (APIの変更を必要とする) 修正が必要だった場合に備えて、1.5.x.x系列が用意されています。この2種類の修正版の系列を用意したのは、Firefox 1.0.5でAPIの変更が行われ問題が多数発生した為1.0.6を要した経験 [slashdot.jp]に基づいています。
明言はされていませんが、例えば 1.5→1.5.0.1→1.5.0.2→(API変更)→1.5.1→1.5.1.1 みたいな感じでリリースされるのではないかと思っています。…判り辛いですね。判り辛いが故に何度か告知されている (Mozilla Developer News » Blog Archive » Extension Versioning in Firefox and Thunderbird 1.5 [mozilla.org], Mozilla Developer News » Blog Archive » Firefox Extension Versioning [mozilla.org]) んですが。
とはいえもっとスマートな方法は無かったのか、とは最初にバージョン付けルールが公開された時に私も思いましたけど。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
普通許容されるのは1.*.*.*という指定だけだと思うけど。
バグ・セキュリティの修正なら原則挙動は変わらないし
インターフェース・機能の修正ならAPIを「追加」すべき。
# Fooに対してFooEx, FooExEx, ...
Firefoxは拡張の資産が非常に重要なんで
1.5.1, 1.6(2.0ですら)が出たらまた拡張全滅という事態は避けないとまずいでしょ。
毎回ユーザーや拡張作者を振り回しても数の力で新陳代謝していけば
何とかなると踏んでいるならそれはひとつの考え方かもしれないけど、
果たして日本はついていけるのか…
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
WindowsのAPIなんかはその増設をやりすぎて、下手なやり方でやって凄いことになってしまってはいるので、この中間位のバランスでやってほしい。
例えば、1.x.x の間はAPIを変えない。もしAPIを変えるなら2.x.xまで我慢するとか。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
番号が違うだけで今もその通りやってる(つもりw)じゃん。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
その対策に「厳密に1.5」という指定の仕方を加えると、今以上に面倒臭くなるだけだと思います。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
その場合は 1.5.0.0 と指定すればいいだけではないのですか?
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)
問題の根本は (スコア:0)
将来どのバージョンで動かなくなるかなんて分かるわけがない。
Re:問題の根本は (スコア:1)
いえ、「寿命」ではなく、現行の最新バージョンを指定すべしというのが、最高バージョン番号設定の基本的なルールになっています。 最新リリース版の番号より新たなものを設定してはならない、という記述がExtension Versioning [mozilla.org]のChoosing minVersion and maxVersion節にあります (既にこの原則は崩れているようですが)。
で、新バージョンがリリースされたら (リリース候補の時点で?)、製作者が互換性を確認し、更新マニフェストファイルを書き換えます。本体の更新時、或いは拡張マネージャで対応版の存在の確認をすると、更新マニフェストファイルを解析して、最高バージョン番号を書き換えます。
つまり、予め寿命を指定するのではなく、(アプリケーション) 本体のバージョンアップ毎にリモートのデータソースを書き換えろ、というのがFirefoxの拡張マネージャの設計です。更新時にプラグインパッケージの読み込みが不要になっていることに注意して下さい (Bug 251473 [mozilla.org])。ちなみにデータソースの量は1kB/拡張・テーマ、程度です。
Re:0.0.0.1を巡る馬鹿騒ぎ (スコア:0)