nova team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxxxx>]

On 13-10-2010 15:34, Rick Clark wrote:
>> In my dictionary, "dot releases" are "micro releases" that come
>> out in between "real releases". We have Austin coming out in a
>> couple of weeks, and Bexar is supposed to follow 3 months after
>> that. A "dot release" of Austin would be another release based on
>> Austin that adds some important bug fixes or similar that we find
>> as we move along (typically backported from later releases).
>> 
>> As an example of a project that does this, Ubuntu designates every
>>  fourth release a "Long Term Support" release. These releases get a
>>  number of dot releases in their lifetime (i.e. support timeframe).
>>  "Regular" Ubuntu releases don't get dot releases.
>> 
>> I don't think we'll want to follow that particular pattern.
> I would rather follow the pattern of KVM, that did not support or 
> backport patches until far down the line.

I agree completely. In fact, I totally stole the model outlined below
from KVM :)

>> Instead, I propose we stick to our three months' (or whatever
>> we'll end up with) cadence. With such frequent releases, the burden
>> of maintaining older releases significantly past their release
>> date doesn't seem worth while for us as a project. However, if
>> someone wants to maintain a stable branch of e.g. Austin, we let
>> them do so within the project. The support and maintenance burden
>> is primarily on them, but we provide the framework for them to do
>> so. We need to work out in detail how this will work, of course,
>> since their work will reflect upon the project as a whole.
> The basic reason for not supporting and backporting patches is that 
> the rate of change in the code is still high.

Again, agree completely. I had a paragraph to roughly the same effect in
my first draft of my e-mail :)

> Fixing bugs in old branches might be completely different work.  We 
> need to focus on moving the project forward, right now.

*nod* That's exactly why I don't think /we/ should be doing it.

> When we reach a point that the rate of change in the code has slowed
> and we are more feature complete we will come up with a full plan to
> support multiple releases.  Until then, we fix all bugs in trunk.

Right. I'm simply trying to acommodate the potential reality of a linux
distro coming along and wanting to ship a particular version of
Openstack and want to support it for a long time. I don't expect that to
happen in the (very) near future. Frankly, I think that would be silly.
Come Ubuntu's next LTS (expected in April 2012), it'll be an entirely
different story. Also way sooner than that.

-- 
Soren Hansen
OpenStack core developer