Release process proposal

Ofer Schreiber oschreib at redhat.com
Thu Feb 16 13:15:54 UTC 2012


Since we currently doesn't have any official Release process, here's my proposal:

1. oVirt will issue a new release every 6 months.
  a. EXCEPTION: First three releases will be issued in a ~3 month interval.
  b. Exact dates must be set for each release.

2. A week after the n-1 release is out, a release criteria for the new release should be discussed.
  a. Release criteria will include MUST items and SHOULD items (held in wiki)
    + MUST items will DELAY the release in any case.
    + SHOULD items will include less critical flows and new features.
    + SHOULD items will be handled as "best-effort" by component owners
  b. Component owners (e.g. Node, engine-core, vdsm) must ACK the criteria suggested.

3. OPTIONAL: Discuses the new version number according to the release criteria/amount of features.
  a. OR BETTER: Increase MAJOR version every second release
  b. Versions will be handled by each component.
  c. The general oVirt version will the engine version.

5. 60 Days before release - Feature freeze
  a. All component owners must create a new versioned branch
  b. "Beta" version should be supplied immediately after.
    + And on a nightly basis afterwards.
  c. Stabilization efforts should start on the new builds.
  d. Cherry-pick fixes for important issues only.
    + Zero/Minimal changes to user interface.
    + Inform in advance on any user interface change.
  e. At this stage, we should start working on the release notes.

6. 30 days before release - release candidate
  a. If no serious issues are found the last release candidate automatically becomes the final release.
  b. Release manager will create a wiki with list of release blockers
  c. Only release blockers should be fixed in this stage.

7. Create a new RC if needed
  a. There must be at least one week between the last release candidate and the final release
  b. Go/No go meetings will happen once a week in this stage.
    + Increase the amount of meeting according to the release manager decision.
    + Release manager will inform the community on any delay.

8. Release
 a. Create ANNOUNCE message few days before actual release.
 b. PARTY

Have any comments? ideas? share them with the list!

Thanks,
Ofer Schreiber.



More information about the Arch mailing list