Table of Contents |
---|
Info |
---|
Note: please refer to previous discussion Business-level Requirements for TF Release Process Initially, due to the absence of release definition and process, community release needs to be aligned with some Contrail commercial release. Once the Community establishes its own independent release definition and process, all commercial releases including contrail can be aligned to community release. This alignment is necessary to allow migration between the community and commercial release. As long as this alignment is maintained, Commercial release can follow any other release frequencies. Aligning with Contrail commercial release to begin with we have following options:
|
The purpose of the release process
...
- Read the Getting Started as a Contributor page (including Registration and User Creation, environment installation)
- Check/assign to one of the existing projects or create a proposal for a new project
Release Process
The unit piece of functionality/work which can be included in the release is represented by the Epic ticket in Jira. The release process consists of several Milestones in the pipeline of epics with clearly defined acceptance criteria. One can treat these acceptance criteria as a checklist that has to be followed to say that particular epic achieved this Milestone. Overall flow is outlined as follows:
- Invitation of proposals for features, enhancement requests - approved till M0
- Blueprints/Design/Architectural approval cut-off date (4 months before release date)
- Code delivery cut-off date (2 months before release date) - till M4
- Branch cut-off date (1 month before release date)
- Stabilize the branch and build daily builds for 1 month
- Release the stable build as Community Release
- Build weekly/bi-weekly if any change committed to the branch
Milestones goal and acceptance criteria
Milestone | Goal of the Milestone | Description of the Milestone - acceptance criteria |
---|---|---|
M0 | Declaration of participation in the release, initial scope of the release |
|
M1 | Identification of dependencies between modules and new functionalities, |
|
M2 | Feature/Functionality technical design freeze |
|
M3 | API freeze (beta available) |
|
M4 | Code freeze - only bug fixing allowed |
|
RC0 | Release candidates freeze - branch stabilization |
|
Deployment | Release deployment | official deployment executed |
Release Cadence, Life Time & Support
The initial release cadence is planned for every 6 months. The initial release process is waterfall-based, but the Community intends to move into a more agile approach in the future.
The Community intends to actively support any release for up to 9 months, where any bug fixes will be committed and made available.
...