incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS][ASFCS40] Status of getting to a 4.0.0 release?
Date Mon, 08 Oct 2012 17:16:23 GMT
On Mon, Oct 8, 2012 at 1:04 PM, Alex Huang <> 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,

View raw message