Proposal: Reorganization of the Project Management
Ayal Baron
abaron at redhat.com
Mon Mar 11 16:15:59 UTC 2013
----- Original Message -----
> Hi Ayal,
>
> On 03/09/2013 10:31 PM, Ayal Baron wrote:
> >> General advice based on my experience with oVirt:
> >> * I recommend a 6 month cadence with ~4 months feature development
> >> and
> >> ~2 months release preparation
>
> <snip>
>
> >> * Make regular point releases (alpha, beta 1, beta 2, RC1,
> >> whatever
> >> they're called) before and after a release. I'm looking forward to
> >> 3.2.1!
> >
> > if we have a 6 month release cycle, do you envision 1-2 point
> > releases?
> > e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and
> > then after another couple of months 3.3?
>
> I was thinking we could lower the cost of making a point release to
> the
> point where we could have a release every month... like this:
I'm not sure I understand what below reduces cost of making the point release.
>
> February: 3.2.0 released
> March: 3.2.1 released - contains fixes for important issues
> discovered
> post-release in 3.2.0 - in the meantime, feature proposal and
> prioritisation (and development) continues on the trunk
> April: 3.2.2 released - only if there are significant bug fixes or
> new
> translations
I have yet to see a month pass without important fixes.
> May: 3.3.alpha1 released - in-progress work, contains some early
> features, aimed for testing to identify features that need additional
> work early. Release branch is made now.
>From this point there are no more point releases to 3.2 then, correct?
> June: 3.3.alpha2 released - corresponds to feature freeze. At this
> stage, incomplete features should no longer be committed. Work can
> start
> on testing, integration testing, bug day
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above, there shouldn't be a 'quiet' period in master as it deters contributors.
> July: 3.3.beta1 released - Corresponds to UI and string freeze -
> translations and docs, and release notes, should be underway already,
> but can hit full speed. Testing and bug fixing continues
>
> August: 3.3.0 released
>
> The only release that should take longer than a couple of hours to
> put
> out is 3.3.0 - the other releases are a tag in the source code, and a
> pointer to specific nightly builds.
I don't see how that is possible. 3.2.1 in this way will contain new features and code which is not fully tested yet (negative flows etc) so you may come out with a release which is less stable than the base version (3.2).
>
> Cheers,
> Dave.
>
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>
More information about the Arch
mailing list