[Engine-devel] 3.3.0.1 Release branch and tracker

[Alon Bar-Lev]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Ofer Schreiber" <oschreib at redhat.com>, "engine-devel"
> <engine-devel at 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 at redhat.com>
> >>> To: "engine-devel" <engine-devel at 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