On Mon, Oct 8, 2012 at 1:04 PM, Alex Huang <[email protected]> wrote:
>>
>> CLOUDSTACK-267: Migration of VM in KVM host is not happening because...
>> Edison, you marked this bug as closed and that it was fixed in
>> c8afd816965786441e4b6f855b141d7515f15f6a.  Was this patch applied to the
>> 4.0 branch?  If so, should we update the fix version to be 4.0.0?
>> If not, should it be applied to 4.0?
>
> I looked at this checkin.  It is in 4.0 branch.  I've updated the bug 
> appropriately.
>>
>> I would also suggest that we consider a 4.0.1 release that includes the
>> completed docs (and nothing else).  I think that once we get ourselves
>> through our first official release process, we shouldn't be shy with 
>> releasing
>> new minor updates.
>
> This is something I do want to discuss perhaps in another thread.  The 
> problem with releases is that there's really no automated testing.  Until we 
> get that almost every release will be difficult.  The QA test cycle for 4.0 
> release was close to three weeks.  I think cutting a release for doc changes 
> (especially since most docs will be online and can be fixed and updated even 
> after the release is over) is probably not worth the effort.
>
> I do think cutting another release to include auto-scaling and brocade and 
> full maven build support might be worthwhile.
>
> --Alex


So we've previously agreed that dot-dot releases (e.g. 4.0.1) could be
released out of cycle to handle really bad bugs, security issues, etc.
I am completely ok with 4.0.1 happening within a few weeks with a
limited scope.
Adding new features is supposed to dictate a dot release (e.g. 4.1)
and we've previously had consensus that we were going to attempt to
have time-based releases. (which is why Brocade, AutoScale, and others
didn't make it in) So in principle, I want the features, but we need
to get some focus on getting a regular time-based release schedule
down, unless, as a group, we decide we are going to abandon our
previous decision for time-based releases. Our previous discussions
suggested 3-4 month release cycles - that is still incredibly rapid,
but gives us time to get new features in, get lots of testing done,
etc.

Reply via email to