WordPress建議使發布周期與行業標準保持一致

WordPress建議與行業標準對齊發布周期WordPress建議與行業標準對齊發布周期

昨天,Francesca Marano開了一家 更改階段的建議 WordPress的核心發布周期。 這是對 討論區 該平台始於2020年10月。目標是使平台的各個階段與更大的開發行業標準保持一致。

除了命名之外,WordPress在處理髮行周期方面一直緊隨軟體行業。 遵循眾所周知的約定可以使WordPress生態系統外部的開發人員更輕鬆地過渡到其中。 它還將允許開發人員關注其他項目的周期,其中許多項目都是WordPress依賴項。 在整個軟體開發領域,這種標準化通常被視為一件好事。

根據自10月以來正在進行的討論,就重命名各個階段以符合標準達成了共識。 下表顯示了每個階段將被重命名為的內容:

現名 建議名稱
1個 規劃和確保團隊領導 初步規劃
2 開發工作開始 Α
3 貝塔 貝塔
4 發布候選 發布候選
5 發射 一般發行

但是,這是一個分為兩部分的提案。 簡單地重命名階段並不會改變發布周期的工作方式。 為了嚴格遵守該標準,WordPress在提交代碼時也需要進行更改。

如何處理Beta階段

如何處理Beta階段存在爭議。 除了在本周期的早期引入的新錯誤修復之外,該標準不需要更改其他代碼。 對於WordPress項目,這會產生問題。

WordPress今年將滿18歲。 多年來,它積累了許多舊錯誤。 這些通常在周期的後期(有時在Beta階段)已修復。 這些較舊的bug可能不是初步計劃階段的一部分,但這是否意味著它們應該等到下一個版本才能使用? 嚴格按照提案,應將其擱置。

它還會強行凍結該發行版的所有增強功能,但這些增強功能不完整。

Josepha Haden在一篇文章中寫道:「我擔心我們不會留出空間來容納並非特定於發行版中計劃功能的較舊的bug。」 對最初的討論發表評論。 「我還擔心,通過在此過程的早期調用硬凍結,我們會大大縮小包含功能的窗口。 我不喜歡現在限制自己出現特定的錯誤,因為這不包括我們的許多自願貢獻者。 由於功能複雜且變化迅速,因此更難使用這些功能,並且較舊的錯誤為臨時貢獻者提供了更多的機會。」

另一方面,錯誤修復有可能引入無法預料的新錯誤。 在Beta版中添加的時間越晚,在「一般發行」階段之前發現此類錯誤的可能性就越小。 等待下一個周期可提供更多時間進行測試。

該系統的優點之一是在Beta測試期間幾乎不會創建任何新的錯誤。 這將使志願者能夠將更多的精力轉移到測試和解決Alpha中出現的問題上。

WordPress始終走在自己的架子上。 它可以更嚴格地遵循標準,同時在項目有意義的情況下可以擺脫嚴格的限制。 不適用於特定發行版的Beta階段錯誤修復可以逐案處理。 我們有擔任領導職務的人員,他們有能力在出現這些呼籲時發出通知。 通過針對次要版本的自動更新,我不太擔心後期的錯誤。

托尼亞·莫克(Tonya Mork) 提出了兩種解決方案 以便缺陷工作在發布周期內和在發布周期前後繼續進行。 兩者都需要WordPress在Beta分支,為貢獻者提供推進修復錯誤的途徑。

第一個建議要求更早的功能凍結,在Beta 1之前的兩到三周內凍結。在Alpha階段結束時,這段時間將專門用於缺陷工作。

第二種解決方案將這一缺陷工作移至與先前版本的Beta和Release Candidate重疊的位置。 這使工作可以在主要版本之間的時間內繼續進行。 它還可能會縮短總體主要發行周期。

第二種解決方案也與Joost de Valk關於處理缺陷工作的思想相一致。 「我認為我們應該早點分支,並保持正常業務的幹線開放,」 他對建議說。 這樣一來,所有內容都可以一直使用,但是根據您提交的時間,它不會包含在下一個版本中。 很好,我在世界上知道的每個開源軟體都可以像WordPress一樣工作。」

當Beta或Release Candidate階段的更改下降時,許多插件和主題開發人員已經很難跟上。 明確界定變化的土地將使擴展生態系統受益,從長遠來看也將幫助最終用戶。 第二種解決方案可以做到這一點。

結合這兩種解決方案也沒有錯。 由於計劃將在Beta階段分支,因此第二個解決方案已通過分支行動實施。 真正的討論是關於該項目在Alpha階段是否應該專門花一些時間來專門解決錯誤。

對該提案的評論將持續到1月20日,然後才能做出最終決定。

下一個建議: 語義版本控制, 任何人? 任何人? 這東西在嗎?

像這樣:

喜歡載入中……

資源

相關文章