----- Original Message ----- > On Thu, Feb 16, 2012 at 2:15 PM, Ofer Schreiber <[email protected]> > 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 > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
