perlpolicy - 與 Perl 核心相關的各種政策和承諾
本文件是主文件，記錄了有關 Perl 5 維護者如何共同開發和維護 Perl 核心的所有書面政策。
perl5-porters 的訂閱者（porter 本身）有幾種不同的類型。有些是安靜的好奇潛水者，很少參與，而是觀察持續的開發，以確保他們預先知道 Perl 中的新變更或功能。有些是廠商的代表，他們在那裡確保 Perl 能持續編譯並在他們的平台上運作。有些會修補任何他們知道如何修復的已回報錯誤，有些會積極修補他們感興趣的領域（執行緒、Win32、regexp 引擎），而另一些人似乎只會抱怨。換句話說，這是一群技術人員的常見組合。
在這些人當中，有 Perl 核心團隊。這些是參與 Perl 語言和直譯器持續開發的受信任志工。他們不需要是語言開發人員或提交者。
Larry Wall 主持這群 porter。對於任何 Perl 程式語言中會變更或不會變更的內容，他擁有最終決定權。這些日子，Larry 將大部分時間花在 Raku 上，而 Perl 5 則由 porter 的指導委員會負責管理，負責決定每個版本要包含的內容，並確保定期發布版本。
Larry 將 Perl 開發視為類似美國政府：有立法機構（porter，由核心團隊代表）、行政部門（指導委員會）和最高法院（Larry）。立法機構可以隨意討論並向行政部門提交修補程式，但行政部門可以自由否決它們。最高法院很少會在立法機構和行政部門之間支持行政部門或立法機構。然而，大多數情況下，立法機構和行政部門應該和睦相處，並在沒有彈劾或訴訟的情況下解決分歧。
你可能會偶爾看到規則 1 和規則 2 的參考。Larry 作為最高法院的權力在規則中表達
Larry 根據定義總是正確地了解 Perl 應如何運作。這表示他對核心功能擁有最終否決權。
Larry 可以在稍後變更他對任何事物的看法，無論他之前是否援引規則 1。
懂了嗎？即使 Larry 錯了，他總是對的。很少看到任何規則被執行，但它們經常被提及。
有關核心團隊和指導委員會成員如何當選或輪替的具體資訊，請參閱 perlgov，其中詳細說明了所有內容。
Perl 5 是由社群而非公司實體開發。對 Perl 核心做出的每一項變更都是捐贈的結果。通常，這些捐贈是社群中個別成員的程式碼或時間貢獻。偶爾，這些捐贈會以公司或組織贊助特定個人或專案的形式出現。
作為一個志工組織，我們做出的承諾在很大程度上取決於沒有義務為 Perl 做出貢獻的個人善意和辛勤工作。
話雖如此，我們重視 Perl 的穩定性和安全性，並且長期以來與更廣泛的 Perl 社群有一項不成文的約定，以支援和維護 Perl 的版本。
本文檔編纂了 Perl 社群應從 Perl 開發人員那裡期待的支援和維護承諾。
我們「正式」支援兩個最新的穩定版本系列。5.30.x 及更早版本現在已停止支援。自 5.36.0 版本發布以來，我們將「正式」終止對 Perl 5.32.x 的支援，除了提供如下所述的安全更新。
盡我們所能，我們將嘗試修復兩個最新穩定 5.x 版本系列中的關鍵問題。當前版本系列的修復優先於前一版本系列的修復。
盡我們所能，我們將為 Perl 的任何主要版本提供「關鍵」安全補丁/版本，其 5.x.0 版本在過去三年內。我們只能承諾在任何 5.x.y 系列中為最新的 .y 版本提供這些版本。
我們不會為 Perl 的開發版本提供安全更新或錯誤修復。
我們鼓勵供應商在程式碼凍結時發布最新支援的 Perl 版本。
作為供應商，您可能需要回溯我們的 3 年支援承諾範圍之外的安全修復。我們可以在您這樣做的過程中提供有限的支援和建議，並在可能的情況下嘗試將這些補丁套用至 git 中相關的 -maint 分支，儘管我們可能選擇不製作編號版本或提供「官方」補丁。請參閱 perlsec 中的「安全漏洞連絡資訊」，以了解如何開始該流程的詳細資訊。
我們的社群長久以來都相信向後相容性是一種美德，即使有問題的功能是設計缺陷。
我們都希望彌補過去幾十年來所犯的一些錯誤。忍受我們所犯的每個設計錯誤可能會導致痛苦的停滯。糾正我們的錯誤非常、非常困難。在不積極傷害我們的使用者的情況下這樣做幾乎是不可能的。
最近，忽視或積極反對與早期版本的 Perl 相容已經成為一種風潮。有時，會提出一個變更，想要篡奪以前有其他意義的語法。有時，一個變更想要改善以前瘋狂的語意。
這條路通往瘋狂。
要求最終使用者程式設計師只變更幾個語言結構，即使是沒有受過良好教育的開發人員永遠不會故意使用的語言結構，等同於說「除非您有 100% 的測試涵蓋範圍，並且可以對您的程式碼庫進行完整的查核，否則您不應該升級到 Perl 的新版本。」如果我們有能夠可靠地將 Perl 原始碼從一個 Perl 版本升級到另一個版本的工具，這個問題就可以大幅減輕。
我們希望確保 Perl 在未來的幾年和幾十年中繼續成長和蓬勃發展，但不會以我們的使用者社群為代價。
現有的語法和語意只應在非常有限的情況下標記為要銷毀。如果它們被認為很少使用、阻礙 Perl 語言或 perl 解譯器的實際改進，並且如果受影響的程式碼可以輕鬆更新以繼續執行，則可以考慮移除它們。如有疑問，謹慎的做法是我們將偏好向後相容性。當某個功能被棄用時，將會發布一份描述決策過程的理由聲明，並且會在相關的 perldelta 文件中提供連結。
在適當的時候，應考慮使用詞彙實用指令來啟用或停用舊有行為，並且在沒有任何實用指令的情況下，應啟用舊有行為。哪些向後不相容的變更會由「use v5.x.y」隱含地控制，這是一個應由指導委員會諮詢社群後做出的決定。
從歷史上看，我們對自己的要求遠高於向後相容性，即向後錯誤相容性。任何實作意外或執行某些程式碼的意外副作用都被視為語言的一個功能，應像捍衛任何其他功能或功能一樣熱心。無論這些意外功能對我們在繼續改進 Perl 時有多麼令人沮喪，這些意外功能通常都值得我們保護。以 Perl 編寫的現有軟體繼續正確執行非常重要。如果最終使用者開發人員已將錯誤視為功能，我們需要將其視為功能。
不會破壞現有語言結構和語法的全新語法和語意，其門檻低得多。它們僅需要證明自己有用、優雅、設計良好且經過充分測試即可。在多數情況下，這些新增內容會被標示為實驗性質一段時間。請參閱下方內容，以進一步了解相關資訊。
為了確保我們在討論從 Perl 核心移除功能或功能性時，所討論的內容相同，我們針對一些字詞和片語制定了特定定義。
如果 Perl 核心中的某項內容標示為實驗性質，我們可能會在不另行通知的情況下變更其行為、棄用或移除它。雖然我們會盡力為實驗性質功能的使用者平穩過渡路徑，但如果你發現某項實驗性質功能很有用，並希望協助塑造其未來，你應該聯絡 perl5-porters 郵件清單。
實驗性質功能必須在兩個穩定版本中都具有實驗性質，才能標示為非實驗性質。只有當實驗性質功能不再有任何針對它們開放的設計變更錯誤，且在整個開發週期中其行為保持不變時，才會撤銷其實驗性質狀態。換句話說，如果 v5.20.0 中存在某項功能，則僅當其行為在整個 v5.21 中保持不變時，才能在 v5.22.0 中標示為不再具有實驗性質。
如果 Perl 核心中的某項內容標示為已棄用，我們可能會在未來從核心移除它，但也有可能不會。一般來說，向後不相容的變更會在移除前兩個版本週期發出棄用警告，但如果風險似乎很低或好處很高，則可能只在一個週期後移除。
從 Perl 5.12 開始，已棄用的功能和模組會在使用時對使用者發出警告。當某個模組已棄用時，它也會在 CPAN 上提供。從 CPAN 安裝它將會讓該模組的棄用警告靜音。
如果您使用已棄用的功能或模組，並認為將其從 Perl 核心移除是一個錯誤，請聯絡 perl5-porters 郵件清單並提出您的論點。我們並非沒有充分的理由就棄用某些功能，但有時我們會遇到尚未考慮的反論。在過去，我們並未區分「已棄用」和「不建議使用」的功能。
有時，我們可能會將我們認為有錯誤的語言結構和功能標記為不建議使用。不建議使用的功能目前並非移除的候選項目，但如果發現它們阻礙了 Perl 核心大幅改善，我們可能會在稍後將它們棄用。
一旦某個功能、結構或模組被標記為已棄用，我們可能會將其從 Perl 核心移除。毫無意外地，我們會說我們已移除這些項目。當某個模組被移除時，它將不再隨 Perl 一起發布，但仍會繼續在 CPAN 上提供。
維護分支的新版本應僅包含屬於以下「可接受」類別的變更，但不得包含屬於「不可接受」類別的任何變更。（例如，如果某個修正會破壞二進位相容性，則不得包含用於修正崩潰錯誤的修正。）
並非所有符合這些條件的變更都必須包含在內，而且一般來說，應著重於解決安全性問題、崩潰錯誤、回歸和嚴重的安裝問題。應避免包含大量不會影響 perl 安裝或執行的次要變更（例如文件中的拼字修正），以降低遺漏某項內容的整體風險。我們的目的是建立有價值且使用者對其穩定性有充分信心的維護版本。（另一個考量是避免讓維護版本管理員筋疲力盡，或讓其他審核要包含的變更的提交者不堪負荷（請參閱以下「將變更納入維護分支」）。）
只要不也屬於以下「不可接受」類別，以下類型的變更可能會被視為可接受
修正 CVE 或安全性問題的修補程式。這些變更應透過安全性回報機制傳遞，而非直接套用；請參閱 perlsec 中的「安全性漏洞聯絡資訊」。
修正崩潰錯誤、斷言失敗和記憶體毀損的修補程式，但不會改變 Perl 的功能或對效能造成負面影響。
修正 Perl 行為中相對於先前版本產生的回歸的修補程式，不論回歸有多舊，因為有些人可能會從非常舊版本的 Perl 升級到最新版本。
修正對應的 5.x.0 穩定版本中新功能的錯誤的修補程式。
修正任何會阻礙或嚴重影響 Perl 建置或安裝的修補程式。
可攜性修正，例如對 Configure 和提示/資料夾中的檔案的變更。
修正特定於平台的測試失敗的最小修補程式。
更正事實錯誤、說明目前實作中的重大錯誤或缺陷，或修正中斷標記的說明文件更新。
對雙重生命週期模組的更新應包含修正崩潰錯誤或安全性問題的最小修補程式（如上所述）。對 CPAN 為正規的雙重生命週期模組所做的任何變更應與上游作者協調。
下列類型的變更不可接受
中斷二進位相容性的修補程式。（請與指導委員會討論。）
新增或移除功能的修補程式。
新增新的警告或錯誤或棄用功能的修補程式。
將 Perl 移植到新平台、架構或作業系統版本，其中包含對實作的變更。
不應將雙重生命週期模組的新版本匯入維護中。這些版本屬於下一個穩定系列。
如果對於特定修補程式是否值得納入維護版本有任何疑問，那麼幾乎可以確定不應納入。
過去，只有單人專案經理會從 bleadperl 中挑選變更並納入 maintperl。這有擴充性的問題。同時，Perl 穩定版本的維護分支需要非常小心地處理。因此，從 Perl 5.12 開始，我們對維護分支有新的處理程序。
任何提交者都可以將任何提交從 blead 挑選到維護分支，方法是先在 maint-votes 分支中相關的投票檔案中新增一個項目，宣告提交為後移植的候選項目，然後等待至少其他兩位提交者新增他們的投票來支持這項提交（亦即，在後移植提交之前，至少需要總共三票）。
收集一組合適的候選提交和挑選已獲得三票的提交的大部分工作將由維護分支版本管理員負責，但如果其他人熱衷於確保某些修正不會被忽略或擔心它們已被忽略，他們可以自由新增其他提案。
也可以使用其他投票機制（例如，寄送郵件到 perl5-porters，並至少有其他兩位提交者回應清單並表示同意），只要以透明的方式收集相同數量的票數即可。具體來說，挑選哪些變更的提案必須對 perl5-porters 上的每個人可見，以便可以聽取所有感興趣者的意見。
對於已挑選的變更相關的挑選 perldelta 項目，不需要進行投票，維護版本管理員也不需要針對Porting/release_managers_guide.pod 所要求的變更取得投票，其中此類變更可以透過從 blead 挑選的方式套用。
以下是一份關於藝術控制的聲明，定義為套件作者引導其程式碼未來發展並維持其作品控制權的能力。這是一種承認，作者應擁有其作品的控制權，而 Perl 社群的其餘成員有責任確保他們保留此控制權。這是一種嘗試記錄我們作為 Perl 開發人員打算約束自己的標準。這是一種嘗試寫下關於我們作為 Perl 開發人員彼此尊重的大致準則。
此聲明並非法律合約。此聲明在任何方式、形式或格式上均非法律文件。Perl 在 GNU 公共授權條款和 Artistic 授權條款下發行；那些是精確的法律條款。此聲明並非關於法律或授權條款。它是關於社群、相互尊重、信任和誠信合作。
我們承認 Perl 核心（定義為與 Perl 本身核心一起發行的軟體）是我們所有人的共同專案。有時，一個指令碼、模組或一組模組（以下簡稱為「模組」）將證明廣泛有用和/或對 Perl 本身的正確運作非常重要，以至於它應與 Perl 核心一起發行。這絕不應在未經作者明確同意的情況下進行，並且所有部分都清楚地認識到這意味著該模組將在與 Perl 本身相同的條款下發行。模組作者應意識到將模組包含到 Perl 核心中必然意味著會失去對它的部分控制權，因為有時可能必須在短時間內或為了與 Perl 的其餘部分保持一致而進行變更。
然而，一旦模組包含在 Perl 核心後，參與維護 Perl 的每個人都應知道該模組仍屬於原始作者的財產，除非原始作者明確放棄其所有權。特別是
Perl 核心中的模組版本仍應被視為原始作者的作品。所有修補程式、錯誤報告等都應回饋給他們。應盡可能尊重他們的開發方向。
若且唯若修補程式非常次要、時間緊迫（例如緊急安全修正程式），或無法聯繫到模組作者，則導向委員會可以在未經模組作者明確合作的情況下套用修補程式。這些修補程式仍必須在可能的情況下交還給作者，而且如果作者在其版本中決定採用其他修正方式，則應強烈優先考慮該修正方式，除非該修正方式存在嚴重問題。任何未經作者認可的變更都應標示為變更，並應承認變更的貢獻者。
與 Perl 一起發布的模組版本應盡可能為作者發布的最新模組版本（在公開 Perl 發行版的案例中為最新非測試版），儘管導向委員會可能會暫緩將與 Perl 一起發布的模組版本升級到最新版本，直到最新版本經過充分測試。
換句話說，應盡可能讓模組的作者對其模組的修改擁有最終發言權（請記住，預期參與其中的每個人都會合作，並在意見分歧時達成合理的妥協）。
然而，作為最後的手段
如果作者對其模組未來的願景與導向委員會和 perl5-porters 整體的願景有顯著不同，以至於對 Perl 造成嚴重問題，則導向委員會可能會選擇正式將 Perl 核心中的模組版本從作者維護的版本中分叉出來。此舉不可輕率，且如果可能的話，務必僅在獲得 Larry 的直接意見後才進行。如果這樣做，則必須在與 Perl 核心一起發布的模組中明確說明它是一個分叉版本，並且雖然它是基於原始作者的作品，但不再由他們維護。這必須在文件和模組來源的註解中註明。
再次強調，這應僅作為最後的手段。理想情況下，這永遠不應發生，且在採取此舉之前應盡一切可能的合作和妥協努力。如果確實有必要為了 Perl 的整體健康而分叉模組，則必須永久給予原始作者適當的認可，並且應持續重新評估此決定，以了解是否有可能在未來重新合併這兩個分支。
在所有與貢獻模組的往來中，每位維護 Perl 的人都應記住，程式碼屬於原始作者，他們可能在任何時間都不在 perl5-porters 上，而且除非補丁程式已整合到作者的模組副本中，否則補丁程式並非官方的。為協助這一點，以及上述第 1、2 和 3 點，所有貢獻模組作者的聯絡資訊應與 Perl 發行版一同保留。
最後，Perl 社群整體而言認知到，對於程式碼所有權的尊重、對於藝術控制的尊重、適當的認可，以及防止意外程式碼偏差或溝通差距的積極努力，對於社群和 Perl 本身的健全至關重要。社群成員通常不應訴諸規則和法律來彼此應對，而本文件雖然包含規則以求明確，但其重點在於一種態度和一般方法。任何爭議的第一步應為公開溝通、尊重對立觀點，以及嘗試妥協。在幾乎所有情況下，都不需要採取更多措施，而且在所有溝通和討論管道都失敗之前，絕對不應使用更激烈的措施。
Perl 的文件是我們使用者的一項重要資源。Perl 的文件合理連貫且準確反映目前實作，這非常重要。
正如 P5P 共同維護程式碼庫一樣，我們共同維護文件。撰寫特定文件並不會讓作者控制該文件的未來。同時，正如原始程式碼變更應符合其周圍區塊的樣式一樣，文件變更也應如此。
文件中的範例應說明它們說明的概念。有時，展示語言功能運作方式的最佳方法是使用讀者可以不修改就執行的簡短程式。更常情況下，範例將包含僅包含「重要」部分的程式碼片段。「重要」的定義因片段而異。有時，宣告 use strict 和 use warnings、初始化所有變數並完全捕捉每個錯誤條件非常重要。然而，更常情況下，這些內容會模糊範例旨在教授的課程。
由於 Perl 是由全球志工團隊開發的，我們的文件經常包含對某人來說看起來很奇怪的拼寫。美國/英國/其他拼寫的選擇留給每段文件的作者自行決定。在修補文件時，請嘗試模仿周圍的文件，而不是變更現有的文字。
一般而言，文件應說明 Perl 「現在」的功能，而非過去的功能。在文件中加入關於行為如何從先前版本變更的註解是完全合理的，但文件並非「雙重生命」——它不需要完全說明所有舊版本如何運作。
perl 開發的官方論壇是上文提到的 perl5-porters 郵件清單，以及其在 GitHub 上的錯誤追蹤器。發文至清單和錯誤追蹤器並非權利：討論中的所有參與者均應遵守行為準則。
始終保持禮貌。
聽從版主的指示。
禮貌很簡單：堅持事實，同時避免貶低他人的言論、輕視他人、諷刺或假設惡意。僅僅陳述事實是不夠的。您還必須保持禮貌。以同樣的方式回應不禮貌的行為是不可接受的。如果您向清單轉發第三方未發布的評論，您將對這些評論的內容負責，因此您必須確保它們是禮貌的。
雖然禮貌是必須的，但鼓勵友善；如果您對自己的禮貌程度有任何疑問，只需問自己：「我是否友善？」並朝此目標努力。
如果清單版主告訴您您不禮貌，請在以任何方式回應之前仔細考慮您的言論如何呈現。它們是否友善？您可以提出抗議，但面對一再重申的決定而重複抗議是不可接受的。一再抗議版主關於第三方的決定也是不可接受的，持續與版主就其決定展開清單外的聯繫也是如此。
不可接受的行為將導致公開且明確指出的警告。同一人第二次出現不可接受的行為將導致從郵件清單和 GitHub 問題追蹤器中移除，為期一個日曆月。這樣做的理由是為此人提供改變行為方式的機會。
在時限禁止解除後，第三次出現不可接受的行為將導致進一步的公開警告。第四次或後續出現將導致無限期禁止。理由是，面對明顯拒絕改變行為，我們必須保護其他社群成員免於未來的不可接受行為。如果相關人士聲明他們不會再次違規，版主可能會解除無限期禁止。
移除，就像警告一樣，是公開的。
版主名單將公開。目前為：Karen Etheridge、Neil Bowers、Nicholas Clark、Ricardo Signes、Todd Rinaldo。
「關於貢獻模組的社會契約」最初由 Russ Allbery <rra@stanford.edu> 和 perl5-porters 撰寫。