...
Community will be actively supporting any release for upto up to 9 months, where any bug fixes will be commited committed and made available. Edward Ting: I am curious if there is enough community developers in addition to Juniper? If the majority is Juniper, how can we support fixes that are important to communities but not necessarily to Juniper?
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? Edward Ting: can we discuss LTS later when we have a community not depending on Juniper?
Next Community Release
Aligning with Contrail commerical release to begin with we have following options: Edward Ting==> can we have the visibility of the feature parity and stability report somehow? In a way, any release is fine, but we'd like to tell the community exactly what they are getting, like features, known issues, etc. Community should be able to take (1) the source or (2) binary to get the same results.
- 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 is outlined as follows Edward Ting: my question is if we have visibility of those right now?
- 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
...