|
| 1 | +# Release Cycle |
| 2 | + |
| 3 | +In Gateway API 1.2+, we will be following a more structured and predictable |
| 4 | +release cycle that is inspired by the [upstream Kubernetes release |
| 5 | +cycle](https://kubernetes.io/releases/release/). |
| 6 | + |
| 7 | +## Goals |
| 8 | + |
| 9 | +* Ensure a predictable release schedule that enables 2-3 releases a year |
| 10 | +* Minimize the amount of time required from upstream API approvers and make it |
| 11 | + more predictable |
| 12 | +* Avoid last minute additions to the scope of a release |
| 13 | +* Prevent experimental channel from growing by requiring GEPs to leave or |
| 14 | + graduate before new ones can be added |
| 15 | +* Ensure that SIG-Network TLs are in the loop throughout the process, and have a |
| 16 | + meaningful opportunity to review changes before a release |
| 17 | +* Provide more advance notice to everyone (SIG-Network TLs, Docs Reviewers, |
| 18 | + Implementations, etc) |
| 19 | + |
| 20 | +## Phases |
| 21 | + |
| 22 | +### 1. Scoping |
| 23 | + |
| 24 | +**Timeline:** 4-6 weeks |
| 25 | + |
| 26 | +In this phase, the Gateway API maintainers and community will be responsible |
| 27 | +for determining the set of features we want to include in the release. Although |
| 28 | +we can always lessen scope after this point, we will avoid expanding the scope |
| 29 | +of the release at a later point unless it is absolutely necessary (critical flaw |
| 30 | +in design, security issue, etc). |
| 31 | + |
| 32 | +A key guideline in this phase is that we want to avoid expanding the size of the |
| 33 | +Experimental release channel. That means that each new experimental feature |
| 34 | +should be accompanied by the graduation or removal of an enhancement that is |
| 35 | +already in the Experimental channel. |
| 36 | + |
| 37 | +Note that in many cases, this scoping work will require some initial work on |
| 38 | +GEPs to determine their viability before committing to including them in a |
| 39 | +release. |
| 40 | + |
| 41 | +### 2. GEP Iteration and Review |
| 42 | + |
| 43 | +**Timeline:** 5-7 weeks |
| 44 | + |
| 45 | +In this phase the Gateway API community will work to update GEPs and meet |
| 46 | +graduation criteria for each feature that has been deemed in scope for the |
| 47 | +release cycle. As we’re working on new features, we will bring these discussions |
| 48 | +to the broader SIG-Network meetings for feedback throughout our development |
| 49 | +process. If a GEP has not merged with the target status by the end of this |
| 50 | +phase, it will be pulled from the scope of the release. |
| 51 | + |
| 52 | +### 3. API Refinement and Documentation |
| 53 | + |
| 54 | +**Timeline:** 3-5 weeks |
| 55 | + |
| 56 | +This phase is entirely focused on translating the concepts defined in the GEP |
| 57 | +(previous phase) into both API specification and documentation. This offers one |
| 58 | +final chance for the Gateway API community to refine the details that have |
| 59 | +already been agreed to in the GEP, but any modifications at this stage should be |
| 60 | +minor. If either documentation or API Spec have not merged by the end of this |
| 61 | +phase, this enhancement will be pulled from the scope of the release. |
| 62 | + |
| 63 | +### 4. SIG-Network Review and Release Candidates |
| 64 | + |
| 65 | +**Timeline:** 2-4 weeks |
| 66 | + |
| 67 | +This phase officially begins with the review session scheduled with SIG-Network |
| 68 | +TLs several weeks earlier in phase 3. In that review session, Gateway API |
| 69 | +maintainers and SIG-Network TLs should reach an agreement on the following: |
| 70 | + |
| 71 | +1. Any blockers for an initial release candidate |
| 72 | +1. How much time, if any, SIG-Network TLs want to review any changes in this |
| 73 | + release |
| 74 | +1. A time after which we can assume lazy consensus and move on with the final |
| 75 | + release of the API |
| 76 | + |
| 77 | +In general, we expect each minor release to be preceded by two release |
| 78 | +candidates. These release candidates will enable implementations to test against |
| 79 | +our release, work out any bugs, and gather early feedback on the viability of |
| 80 | +the release. |
| 81 | + |
| 82 | +## Contributions Welcome in Each Phase |
| 83 | + |
| 84 | +The following table illustrates when different kinds of contributions will be |
| 85 | +welcome. There will be some exceptions to this, but it should be useful as an |
| 86 | +overall guideline: |
| 87 | + |
| 88 | +| | 1. Scope | 2. GEP | 3. API | 4. Review | |
| 89 | +| - | :-: | :-: | :-:| :-: | |
| 90 | +| New GEPs | ✅ | ❌ | ❌ | ❌ | |
| 91 | +| Major GEP Updates | ✅ | ✅ | ❌ | ❌ | |
| 92 | +| GEP Refinement | ✅ | ✅ | ✅ | ❌ | |
| 93 | +| API Spec Additions | ❌ | ❌ | ✅ | ❌ | |
| 94 | +| New Conformance Tests | ✅ | ✅ | ✅ | ❌ | |
| 95 | +| Bug Fixes | ✅ | ✅ | ✅ | ✅ | |
| 96 | +| Documentation | ✅ | ✅ | ✅ | ✅ | |
| 97 | +| Review | ✅ | ✅ | ✅ | ✅ | |
| 98 | + |
| 99 | +## Timeline |
| 100 | + |
| 101 | +Given the above, we expect each release to take 14-22 weeks (4-5 months). At |
| 102 | +least initially, Gateway API maintainers will set end dates for each phase as we |
| 103 | +are beginning the phase. In future releases, we may choose to set all dates for |
| 104 | +the release in advance. |
0 commit comments