Next Release Planning

[Livnat Peer]

On 21/08/12 17:01, Ryan Harper wrote:
> * Dave Neary <dneary at redhat.com> [2012-08-21 08:42]:
>>> 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.
> 
> Definitely agree with this approach.  We always want something new for
> the next release.  

I agree we want something new, the question is what is the release criteria.
If I understand the above suggestion correctly If there are not enough
new features we won't release in 3 months?
I think this is a mistake because there are hundreds of bug fixes pushed
into the repository and releasing a more stable version IMO has great value.

For example in Networking we fixed one feature and will probably add one
small feature by November, but I know that networking in 3.1 release is
very buggy while if you take latest from upstream it is dramatically
better, regardless of the features there is a value for releasing in
November.

> 
> It's probably worth keeping a list of features from each of the
> sub-projects as a potential next-release feature list.  And with a
> defined release cycle, we can see which features will make the cut prior
> to a feature-freeze date.
> 
> IMHO, one of our challenges is actually enumerating all of the potential
> features.  I think there are lots of features under development, but I
> don't think we're collecting all of that info in a single place where
> you can get a view of potential features in the various sub-projects.
> 
>>
>> 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.
> 
> +1
> 
>>
>> Cheers,
>> Dave.
>>
>> -- 
>> Dave Neary
>> Community Action and Impact
>> Open Source and Standards Team, Red Hat
>> Phone: +33 9 50 71 55 62
>> _______________________________________________
>> Board mailing list
>> Board at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/board
>