----- Original Message -----
> From: "Itamar Heim" <ih...@redhat.com>
> To: "Dan Kenigsberg" <dan...@redhat.com>
> Cc: "Alon Bar-Lev" <alo...@redhat.com>, "Ofer Schreiber" 
> <oschr...@redhat.com>, "engine-devel"
> <engine-devel@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" <oschr...@redhat.com>
> >>> To: "engine-devel" <engine-devel@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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Reply via email to