Release process proposal

[Mike Burns]

On Thu, 2012-02-16 at 08:15 -0500, Ofer Schreiber wrote:
> 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.
	decided week after previous 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.

Seems case-by-case is better for this.  Probably depends what changes
are made and how big they are.  

> 
> 5. 60 Days before release - Feature freeze
I assume 30 days (maybe 45?) for the first couple releases since they're
only 3 month intervals...
>   a. All component owners must create a new versioned branch
>   b. "Beta" version should be supplied immediately after.
>     + And on a nightly basis afterwards.
that's huge overhead on each component owner/builder unless we get some
process of delivering these from jenkins for each component.
>   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
	15 days for first few releases? 20?
>   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!

Should there be a step for RPM and binary signing?

> 
> Thanks,
> Ofer Schreiber.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch