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