Next Release Planning

[Livnat Peer]

On 21/08/12 22:00, Ryan Harper wrote:
> * Livnat Peer <lpeer at redhat.com> [2012-08-21 13:23]:
>> 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.
> 
> This is what a stable release stream is for.  QEMU maintains a stable
> release until the next version is available.  We could produce a 3.1.1
> release and keep that going until 3.2 comes out.
> 
> And if we don't have new features in 3 months, then it's probably too
> short of a release cycle.  The last thing we want to do is introduce
> *more* churn into engine deployments.  If we have a stable release, this
> would make a longer cycle, like 6 months, more reasonable.
> 

I'm perfectly fine with releasing in November a 3.1.1 as a stable
release. As long as we don't postpone releasing 'something' further than
November.

The only issue that comes to mind when we start discussing z-stream is
the churn we'll have (as developers):

- We'll need to cherry pick instead of rebasing, which means sending
patches twice, testing it twice, rewriting parts if needed etc. It would
have been ok if we didn't have to cherry pick a few dozens patches in
networking alone.

- We'll need to take care of upgrades more carefully, which always makes
our work more interesting but also more complicated (do we require
upgrading to 3.1.z before upgrading to 3.2? testing the upgrade process
etc.)

I think that going forward we'll do better if we can create the next
z-stream branch as soon as we release so we can cherry pick as we go,
now we have a gap of about 8 weeks (? - not sure actually) since last
rebase, that's a lot of work.

I suggest that the release in November will still be 3.2 and hopefully
we can get enough features to make it attractive, and then we'll create
the z-stream branch, so we can release 3.2.z as needed (instead of doing
3.3 with not enough meaningful content).


>>
>> 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.
> 
> definitely material for a stable release.
> 
>