From: "Itamar Heim" <iheim(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Ofer Schreiber"
<oschreib(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, September 25, 2013 2:18:42 PM
Subject: Re: [Engine-devel] 3.3.0.1 Release branch and tracker
On 09/25/2013 11:53 AM, Dan Kenigsberg wrote:
> On Wed, Sep 25, 2013 at 03:49:40AM -0400, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Ofer Schreiber" <oschreib(a)redhat.com>
>>> To: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, September 25, 2013 10:40:33 AM
>>> Subject: [Engine-devel] 3.3.0.1 Release branch and tracker
>>>
>>> Hey,
>>>
>>> As you may know, we're planning to release oVirt 3.3.0.1 soon.
>>> I've created a tracker bug
>>> (
https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch
>>> (ovirt-engine-3.3.0.1, based on 3.3.0) for this release.
>>>
>>
>> Once again, I do not understand why go into 4 digit version and not
>> release 3.3.1 as z-stream, deferring remaining queue to 3.3.2.
>>
>> The argument of small/large change is irrelevant in z-stream as something
>> small for one can be important for other.
>>
>> The number should not be important, whenever z-stream is released you take
>> last+1.
>
> hear hear. Z is the last letter of the English alphabet. We should not
> go past it, unless 3.3.1 was already in beta and we have to ship a quick
> 3.3.0.1.
>
because we should be able to number things and plan to them. not have to
revisit all ovirt bugs targeted to 3.3.1 and change them to 3.3.2, since
we need to do something in async, etc.
we also communicated 3.3.1 will have a rebase, or will have something
specific around it. we can't re-number the messaging for every async update.
We are not the only project that cope with z-stream. There is no reason to be unique.
There is expected scheme of release management and versioning scheme, let's not
re-invent the wheel.
Pushing in bugzilla all 3.3.1 -> 3.3.2 is simple task, and as release maintainer does
that, he may find that some of the fixes applied to 3.3.1 should remain in 3.3.1 and
better released at that chance.
Regards,
Alon