You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The entirety of the commit → review → test → integration → build → release process

Introduction

This document provides a clearing house to provide high level guidance to the TF TSC for delivering more detailed requirements for the entire release process, from code commit, to review, through testing, and final build and release.

Questions to Answer / Outcomes to Accomplish (please add)

  • What is the release cadence?
  • Are there multiple types of release? e.g. experimental, daily, stable, production?
  • Will we have LTS releases or is that a problem for vendors making distributions?
  • 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?
  • Are releases tagged? Are features tagged? Are tagged features included in a release?
  • Or do we operate in branches?
  • What infrastructure is required to support the release plan?
    • Where is it hosted?
    • Who is contributing?
  • What are the quality criteria for release?
  • What are the security criteria for release?
  • What are the documentation criteria for release?

Requirements

  1. Releases MUST have a web/wiki page that explains exactly what is in the release
    1. The page SHOULD be automatically generated if at all possible


  • No labels