Next Release Planning

[Dave Neary]

Hi,

On 08/21/2012 03:01 PM, Livnat Peer wrote:
> On 21/08/12 15:31, Mike Burns wrote:
>> On Tue, 2012-08-21 at 00:30 +0300, Itamar Heim wrote:
>>> in general, I think it should be a 3-month version (we said we wanted to
>>> move to 6 months cycle after the first few versions. I think we should
>>> stay on 3 months especially since 3.1 took longer to get the final
>>> blockers out and until released).
>>
>> I think I agree on the shorter time-table for 3.2.  I also think we
>> should get a list of features and commit to it and track against it on
>> the weekly call.  The 3-month schedule would put us in mid-November to
>> early-December which I think is reasonable.

My only concern committing to a 3 month cycle for this release is that 
all we would have time for are bug fixes. Especially with work on RHEV 
3.1 happening in parallel.

> I agree we should keep the short cycles, so many things changed and so
> many fixes were pushed, I see no reason to hold the next release for
> longer than 3 month + some blockers delay.

How long was 3.1 in feature freeze? Are there newer features or 
developments that were done on a devel branch while it was in stabilisation?

I'd prefer not to see us plan for delays! If they happen, so be it, but 
we should be able to identify most of the blockers early enough to avoid 
schedule skips, I hope.

> I am not sure we must have new features in each release, a release of
> bug fixes seems also reasonable to me. Why not keep it only time-based
> release regardless of commitments for new features for the release.

I like giving people good reasons to upgrade, but also good reasons to 
install the current version - and in terms of communication, if we say 
that 3.2 will be "3.1, with lots of bug fixes", and that it will be 
along in 3 months, why would anyone install 3.1? We've just said it's a 
buggy release that will soon be obsoleted anyway.

IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 
will be able to do that 3.1 doesn't". I'm not suggesting a revolution 
with every release, but one thing which is identifiable as "new in 3.2" 
doesn't seem like a lot to ask.

That said, I have previously worked on a project, where we had one full 
release cycle whose goal was "make it work better on Linux", and it was 
a very positive release cycle, lots of new contributors and energy, 
because it was a goal people cared about. So purely bug-fix & 
stabilisation releases can work, if you have a measurable goal to 
compare against.

> We can ask what new features are planned/expected to be pushed in the
> near future, if we get reply with a lot of features then we can call it
> major version (4.0) if we get only minor features we can use a minor
> version (3.2, 3.3, etc).

I don't care about major/minor versions - I have been in far too many 
discussions in both GNOME and GIMP on whether a release is "worth" a new 
major version. Personally, I have a view which is much like that of 
Queen Victoria towards bathing: I'm happy with incrementing the major 
version every year or two, whether it's needed or not.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards Team, Red Hat
Phone: +33 9 50 71 55 62