Release process proposal

[Alan Pevec]

On Thu, Feb 16, 2012 at 2:15 PM, Ofer Schreiber <oschreib at redhat.com> 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.
...
> 5. 60 Days before release - Feature freeze

For first three, 30 days before release probably makes sense.

>  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.

To clarify, all patches go to the trunk first and get cherry-picked to
versioned branched.

>    + Zero/Minimal changes to user interface.
>    + Inform in advance on any user interface change.

Also any API or changes which affect other components, e.g.
vdsm/ovirt-node interactions got broken in the past

>  e. At this stage, we should start working on the release notes.
>
> 6. 30 days before release - release candidate

14 days/2 weeks for first three 3-months releases

>  a. If no serious issues are found the last release candidate automatically becomes the final release.

That means, "rcN" will not be included in the version-release string?
What would be release tarball named?
I see current tarball for engine includes sequence after version
http://www.ovirt.org/releases/stable/src/
but node and sdk are just name-version - would each RC be simply bump
in version major.minor.micro ?
Should we maybe unify naming across all projects?

>  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

YES!
But wait, before that, let's document also what needs to be uploaded
and where :)

Cheers,
Alan