| 29 | | GitHub pull requests can be used to ''preliminary'' review, or to gather feedback about the patch. |
| 30 | | |
| 31 | | == Making a release == |
| 32 | | |
| 33 | | Prior to making a release the following happens: |
| 34 | | |
| 35 | | * Features to include will be selected from the "testing" tree |
| 36 | | * Features will be stabilized until they don't change much |
| 37 | | * A staging "stable candidate" branch will be created |
| 38 | | * Beta release will be published based on this staging branch (to get people to _really_ test the code) |
| 39 | | * This should have most features for the release included, and as such be mostly testing and bug fixing. However, new features could still change as much as needed and old features could be changed if absolutely needed. |
| 40 | | * RC release will published based on this staging branch |
| 41 | | * This should focus only on stabilisation and bugfixes. At this point we know for sure which features should be included. Only in worst cases should a feature taken out, e.g. if it really is horrendous to stability. |
| 42 | | * Once staging branch is deemed stable enough, an official release will be made |
| 43 | | |
| 44 | | In the IRC meeting on [https://community.openvpn.net/openvpn/wiki/IrcMeetings 22nd July 2010] it was decided to aim for 6-12 month release cycle to keep the need for large-scale testing minimal. |
| 45 | | |
| 46 | | == Feature deprecation == |
| 47 | | |
| 48 | | Feature removal process (aka FRP) is another workflow which also goes through the general workflow to get a feature removed.. This process serves two purposes: |
| 49 | | |
| 50 | | * Maintain backwards compatibility and minimize the impact of feature removal (for users) |
| 51 | | * Keeping the codebase clean and understandable (for developers) |
| 52 | | |
| 53 | | The ''Feature removal process'' is described in detail on [wiki:FRP this page]. |
| | 29 | !GitHub pull requests can be used to ''preliminary'' review, or to gather feedback about the patch. |
