|
1 | 1 | .. _governance: |
2 | 2 |
|
3 | | -Lightning Governance | Persons of interest |
4 | | -========================================== |
| 3 | +Lightning Governance |
| 4 | +#################### |
| 5 | + |
| 6 | +This document describes governance processes we follow in developing PyTorch Lightning. |
| 7 | + |
| 8 | +Persons of Interest |
| 9 | +******************* |
| 10 | + |
| 11 | +.. _governance_bdfl: |
5 | 12 |
|
6 | 13 | BDFL |
7 | 14 | ---- |
|
14 | 21 | ----- |
15 | 22 | - Jirka Borovec (`Borda <https://github.com/Borda>`_) |
16 | 23 | - Ethan Harris (`ethanwharris <https://github.com/ethanwharris>`_) (Torchbearer founder) |
17 | | -- Justus Schock (`justusschock <https://github.com/justusschock>`_) (Former Core Member PyTorch Ignite) |
| 24 | +- Justus Schock (`justusschock <https://github.com/justusschock>`_) |
18 | 25 | - Adrian Wälchli (`awaelchli <https://github.com/awaelchli>`_) |
19 | 26 | - Thomas Chaton (`tchaton <https://github.com/tchaton>`_) |
20 | 27 | - Sean Narenthiran (`SeanNaren <https://github.com/SeanNaren>`_) |
@@ -44,3 +51,50 @@ Alumni |
44 | 51 | - Teddy Koker (`teddykoker <https://github.com/teddykoker>`_) |
45 | 52 | - Nate Raw (`nateraw <https://github.com/nateraw>`_) |
46 | 53 | - Peter Yu (`yukw777 <https://github.com/yukw777>`_) |
| 54 | + |
| 55 | + |
| 56 | +Releases |
| 57 | +******** |
| 58 | + |
| 59 | +We release a new minor version (e.g., 1.5.0) every three months and bugfix releases every week. |
| 60 | +The minor versions contain new features, API changes, deprecations, removals, potential backward-incompatible |
| 61 | +changes and also all previous bugfixes included in any bugfix release. With every release, we publish a changelog |
| 62 | +where we list additions, removals, changed functionality and fixes. |
| 63 | + |
| 64 | +Project Management and Decision Making |
| 65 | +************************************** |
| 66 | + |
| 67 | +The decision what goes into a release is governed by the :ref:`staff contributors and leaders <governance>` of |
| 68 | +Lightning development. Whenever possible, discussion happens publicly on GitHub and includes the whole community. |
| 69 | +For controversial changes, it is mandatory to seek consultation from :ref:`governance_bdfl` for a final decision. |
| 70 | +When a consensus is reached, staff and core contributors assign milestones and labels to the issue and/or pull request |
| 71 | +and start tracking the development. It is possible that priorities change over time. |
| 72 | + |
| 73 | +Commits to the project are exclusively to be added by pull requests on GitHub and anyone in the community is welcome to |
| 74 | +review them. However, reviews submitted by |
| 75 | +`code owners <https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/CODEOWNERS>`_ |
| 76 | +have higher weight and it is necessary to get the approval of code owners before a pull request can be merged. |
| 77 | +Additional requirements may apply case by case. |
| 78 | + |
| 79 | +API Evolution |
| 80 | +************* |
| 81 | + |
| 82 | +Lightning's development is driven by research and best practices in a rapidly developing field of AI and machine |
| 83 | +learning. Change is inevitable and when it happens, the Lightning team is committed to minimizing user friction and |
| 84 | +maximizing ease of transition from one version to the next. We take backward compatibility and reproducibility very |
| 85 | +seriously. |
| 86 | + |
| 87 | +For API removal, renaming or other forms of backward-incompatible changes, the procedure is: |
| 88 | + |
| 89 | +#. A deprecation process is initiated at version X, producing warning messages at runtime and in the documentation. |
| 90 | +#. Calls to the deprecated API remain unchanged in their function during the deprecation phase. |
| 91 | +#. Two minor versions in the future at version X+2 the breaking change takes effect. |
| 92 | + |
| 93 | +The "X+2" rule is a recommendation and not a strict requirement. Longer deprecation cylces may apply for some cases. |
| 94 | + |
| 95 | +New API and features are declared as: |
| 96 | + |
| 97 | +- *Experimental*: Anything labelled as *experimental* or *beta* in the documentation is considered unstable and should |
| 98 | + not be used in production. The community is encouraged to test the feature and report issues directly on GitHub. |
| 99 | +- *Stable*: Everything not specifically labelled as experimental should be considered stable. Reported issues will be |
| 100 | + treated with priority. |
0 commit comments