...
- What is the release cadence?
- JG I think anything faster than 6 months is not realistic, maybe we should start with 9 months.
- DAH How will we communicate features / APIs that get deprecated?
- Are there multiple types of release? e.g. experimental, daily, stable, production?
- JG Let's start with having CI in place and just one release (doesn't need to be called anything). Small steps to start with, we can go faster if we feel comfortable later.
- Will we have LTS releases or is that a problem for vendors making distributions?
- JG No need for LTS releases to start with IMHO
- Is there variance in the release cadence for the different types of release?
- How are these releases tested differently? For example:
- Experimentals get basic sanity tests that are hours in length
- Weekly stable releases get multi-day sanity/burn in tests
- Production releases get month long scalability, performance tests, and synthetic transaction testing with VNFs or other workloads
- How do we determine what goes in a release?
- JG From the blueprints
- Are releases tagged? Are features tagged? Are tagged features included in a release?
- JG Absolutely releases should be tagged. Big features can have their branches and then those branches get merged back.
- Or do we operate in branches?
- What infrastructure is required to support the release plan?
- Where is it hosted?
- Who is contributing?
- JG These are important questions that need to be answered. We need CI/CD in place. Without it it is nearly impossible to have stable releases. We need to also have performance testing as part of CI. We do need a contributors list too. Both developers and devops that run the whole CI engine.
- What are the quality criteria for release?
- What are the security criteria for release?
- What are the documentation criteria for release?
...