**draft**
Note: please refer to previous discussion Business-level Requirements for TF Release Process
Release Frequency
Proposal is to have a community release every 6 months.
Intially due to absence of release definition and process, community release needs to be aligned with some Contrail commerical release. Once Community establishes its own independent release definition and process, all commerical release including contrail can be aligned to community release.
This alignment is necessary to allow migration between community and commercial release. As long as this alignment is maintained, Commercial release can follow any other release frequencies.
Release Life Time & Support
Community will be actively supporting any release for up to 9 months, where any bug fixes will be committed and made available.
LTS release: Community recognising a need to have Long term support release, will look forward to introduce a mechnism to term a community release as LTS release. where any LTS release will be actively supported by community for upto ?2/3 years?
Next Community Release
Aligning with Contrail commerical release to begin with we have following options:
- We do a release out of old branch R1911 now to bridge the gap from the last community release of r5.1 and look forward to do next release in June, 2020 aligning with Contrail release of June
- We skip the releases between r5.1 and R2002, and look forward to do next release in March, 2020 aligning with Contrail release of March
Release Process
Release process is outlined as follows
- Invitation of proposals for features, enchancement requests
- Blueprints/Design/Architectural approval cut-off date (4 months before release date)
- Code delivery cut-off date (2 months before release date)
- Branch cut-off date (1 month before release date)
- Stablise the branch and build daily builds for 1 month
- Release the stable build as Community Release
- Build weekly/bi-weekly if any change commited to branch