[1] 非互換変更とは、プロトコル、言語、その他の仕様における、 以前の版との後方互換性・相互運用性が失われるような変更をいいます。
[2] 一般に非互換変更は好ましくないものと認識されていますが、 にも関わらず、体系的整合性や政治的正当性などを根拠に、 あるいは影響を過小評価した結果としてしばしば行われ、 混乱を招いています。
U-00110000
以上の符号位置の廃止BELL
の文字の名前の問題 \p
の仕様変更usemap
isindex
,
keygen
,
blink
の廃止target=_blank
の noreferrer
化img
の image-orientation
既定値の変更showModalDialog
の廃止beforeunload
の仕様変更capabilities
への変更use encoding
の廃止DBD::mysql
の MariaDB 非対応化DBD::mysql
の TLS 対応コンパイルオプション廃止 [62] 嶋田大貴さんはTwitterを使っています: 「PHP 5時代のプログラムを PHP 7でなんとか動かしている人へ。 PHP 8でかなりの非推奨機能が削除されて動かなくなるので覚悟しといたほうがいいですよ。」 / Twitter, , https://twitter.com/shimariso/status/1592404249371365377
[85] 関連: 読めなくなったファイル
[75] The future is longer than the past. は非互換変更を正当化する合言葉です。
[76] 目論見通り past を抹消するのは難しいです。 広く行き渡っているものなら抹消しきれなくて future に恒久的に禍根を残すことになりがち。 そうでもないものなら混乱で見切りをつけられて future が消滅しちゃったり。
[71] 高輪ゲートウェイ駅開業にあわせて未来への決断をおこなったJR東日本 | muo-ya, https://b.muo.jp/2020/03/14/takanaga-gw.html
田町駅のコードをずらして高輪ゲートウェイ駅を配置したことで、駅改札機での履歴出力はもとよりSuica Readerを始めとするICカード履歴読み取りツールや各種経費精算ツールでも日付をもとにした分岐処理が必要となります。
JR東日本はこれを承知のうえで、過去データとそれを読み書きするソフトウェアの一時的な混乱よりも、未来に向けて整った駅順コードを優先するという判断をおこなったことになります。
正直なところ、駅順コードに関しては過去データの扱いを優先して徐々にぐちゃぐちゃになって歴史的経緯として刻まれていくもの、と考えていたので、今回のJR東日本の対応には驚きがありました(羽田空港国際線開業時の京急やほか一部モノレールなどで事例はあるものの)。
[72] Kei NakazawaさんはTwitterを使っています: 「JR東の決断に驚きつつ感動したので書いた 高輪ゲートウェイ駅開業にあわせて未来への決断をおこなったJR東日本 | muo-ya https://t.co/tDSrQ8cTwW」 / Twitter, , https://twitter.com/muo_jp/status/1238682168911466497
[73] こうやって非互換変更を美化できるのは傍観してるだけの部外者だからかなあ
[74] 六ミツさんはTwitterを使っています: 「家を整理してたら古いSuicaが出てきて、2005年のデータを読み取ることに成功したが、はて? 当時存在しない高輪ゲートウェイが出てきたぞ? https://t.co/jwuuCf9M3C」 / Twitter, , https://twitter.com/rokumitsu/status/1666263265985593345
[16] なぜみんな非互換変更を好むのか。
[68] セキュリティーなどやむを得ないこともあるのですが、 開発者が良かれと思って積極的に非互換変更するとか、 過去の失敗に学ばず同じものを再変更したりとか、 闇が深い事例が少なくないのがまたなんとも。
[69] 何もしなくても解釈の違いで製品によって非互換になってしまうことがよくあるのに、 意図的に非互換に変更するのは悪質だよなあ
[70] プロトコルの脱共有化勢力の暗躍かもしれない(陰謀論)