看到 Eric Meyer 弄了 BCD Watch 觀察 MDN 上面的 Browser Compatibility Data 變化:「Announcing BCD Watch」。
看起來是每個禮拜更新一次,而網站有提供 RSS feed 可以訂閱,所以不用自己一直跑去翻。
這種網站果然是掛在 GitHub Pages 上面 (+ GitHub Actions),專案則是在 https://github.com/bkardell/bcd-watch 這邊可以看到。
幹壞事是進步最大的原動力
看到 Eric Meyer 弄了 BCD Watch 觀察 MDN 上面的 Browser Compatibility Data 變化:「Announcing BCD Watch」。
看起來是每個禮拜更新一次,而網站有提供 RSS feed 可以訂閱,所以不用自己一直跑去翻。
這種網站果然是掛在 GitHub Pages 上面 (+ GitHub Actions),專案則是在 https://github.com/bkardell/bcd-watch 這邊可以看到。
HashiCorp 的東西都還蠻有品質的 (相較於其他的類似方案),其中有一個觀察到的特性是,如果他門把版本維持在 0.x,代表他們自己對軟體的品質與成熟度都不算滿意。
而 Terraform 算是他們家對於基礎建設資源管理所提出的方案 (尤其是雲端時代的資源),不過之前最頭痛的,每次升級就會發現有些基本的概念會被改掉,所以不是改改關鍵字就可以解決。
這次 Terraform 推出 1.0 版,代表了他們認為產品有一定的成熟度:「Announcing HashiCorp Terraform 1.0 General Availability」,另外在 GitHub 上面的「Release v1.0.0 · hashicorp/terraform」也可以看到:
Terraform v1.0 is an unusual release in that its primary focus is on stability, and it represents the culmination of several years of work in previous major releases to make sure that the Terraform language and internal architecture will be a suitable foundation for forthcoming additions that will remain backward compatible.
另外也可以從他們對相容性的宣示「Terraform v1.0 Compatibility Promises」看出來他們覺得架構上成熟了:
For all future minor releases with major version 1, we intend to preserve backward compatibility as described in detail in the Terraform v1.0 Compatibility Promises. The later Terraform v1.1.0 will, therefore, be the first minor release with new features that we will implement with consideration of those promises.
總算是開始進入會考慮 backward compatibility 的週期了...
看到 WordPress 的這篇「WordPress and PHP 8.0」,看起來 PHP 8.0 快要出了:
PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.
官網上已經有一些資料可以看了,不過記得畢竟還沒 release,裡面的資訊還有可能會修正:「Migrating from PHP 7.4.x to PHP 8.0.x」,最重要的應該還是「Backward Incompatible Changes」這邊,可以看到這次畢竟是主版號升級,精彩的不相容性應該會搞爆不少應用程式,像是開頭就提到的,對數字與文字之間的 ==
行為改變:
比較好的作法是自己先轉型再用 ===
比較,這個概念在各家程式語言都類似,loose comparison 只是方便而已...
同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。
很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)
在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。
所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:
Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.
目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...
官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?
Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.
也有可能是放個話讓 IdenTrust 表態?先繼續看下去...
最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...
Composer 是目前 PHP 世界裡比較紅的套件管理工具,內建了一些 autoload 模組,以及 Packagist 這個巨大的 ecosystem。
在「Installing Composer Packages」這篇文章裡提到要如何在 Composer 裡指定套件的版本。在這之前,你需要先知道什麼是 Semantic Versioning,然後再來看作者的論述。
直接講結論,文章裡推薦用 ~
的方式指定版本,這通常會是你要的結果:用 ~1.2
表示 >=1.2.0,<2.0.0
;而用 ~1.2.3
則可以表示 >=1.2.3, <1.3
。
在對付 compatibility 問題時還蠻常見的情況。
順便可以拿來取消版本檢查...
我桌機的 Firefox 雖然是跑 3.6 系列,但筆電上還是跑 Minefield。之前一直都是靠 Nightly Tester Tools 強制套件不要檢查版本,但在 4.0 beta 後一直沒更新,於是 Nightly Tester Tools 就失效了... XD
後來在 comment 的地方看到有人說 Mozilla 官方自己跳出來弄了一個「Add-on Compatibility Reporter」,一樣可以做到這件事情,除此之外還可以回報套件在新版上是否正常...
於是 Minefield 的套件就都跑起來了,測了一下,果然一堆套件在 4.0b3 上爛掉... XD
WordPress 宣佈從 3.1 版開始將不再支援 PHP 4 與 MySQL 4:「PHP 4 and MySQL 4 End of Life Announcement」。
PHP 4 與 MySQL 4 官方都已經停止支援很久了,WordPress 總算是想起來了?
另外,在 WordPress 3.2 版後 (預定在 2011 年的上半年發行),對 PHP 的最低需求會再提高到 5.2 版,這是因為目前使用非 5.2 以上的數量只有 ~11%,所以他們希望半年後可以再把需求更新...