Release process proposal

[Ofer Schreiber]

----- Original Message -----
> 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?

Well, we can rebuild the binaries with on the same git hash, just without the RCx string
about the engine - the _0001 is part of the version, hope to remove this next build.

I don't care so much about naming conventions. 
maybe enforce the "Beta" and "RC" strings when needed.

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