cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS] releases going forward
Date Fri, 09 Nov 2012 21:42:22 GMT
On Fri, Nov 9, 2012 at 3:56 PM, Alex Huang <> wrote:
>> -----Original Message-----
>> From: Rohit Yadav
>> Sent: Wednesday, November 07, 2012 9:23 PM
>> To:
>> Cc: Alex Huang; Childers
>> Subject: Re: [DISCUSS] releases going forward
>> On 08-Nov-2012, at 5:52 AM, Caleb Call <> wrote:
>> > From a non-developer perspective, more releases shows a project is
>> actively being worked-on/improved.  We I'm looking at new projects to fill
>> needs, that's definitely something I look at.
>> Yes, but if we ignore the frequently released browsers who've reached some
>> major version like 24.x (chrome), 16.x (for mozilla) and who knows by the
>> time you read this email they might have released one more :) A CloudStack
>> user may not want to upgrade every week or month but can do quarterly or
>> half yearly release upgrades.
>> Alex, Chip; May we can do major releases every 4-6 months and do
>> maintenance/bugfix releases every 2-3 months?
> Here's my $.02 on this.
> I am +1 on shorter releases.  But I don't think it's practical to do right now.
> Here's my reasoning.  We pushed out 4.0 release.  A lot of it was to make it compatible
with apache licensing.  But, for me at least, it's also because it didn't make sense to not
have an apache release after being contributed to apache for six months.  However, we identified
a lot of things in this release: unit testing, review process, doc process, lack of infrastructure,
automated testing, long test cycles.   I don't know how it was for Chip but for me it was
quite frustrating.
> To me we have to regroup as a community and tackle each of these issues before our next
big release.  So for me, what Kevin proposed actually makes sense until we've tackled these
issues.  Now, we don't have to get everything perfect but we should figure out how we're going
to improve and how to measure that improvement release to release.

The problem is that we fundamentally agreed to do time based releases
because a known cadence is good for our community and consumers. It
properly sets expectations. Saying we can't do another release until
we have unit testing, doc processes, infrastructure in place,
automated testing, and a reduction in length of time a test cycle
takes is effectively the 'list of features' for the next release, and
if we can't release without them we might as well ditch the idea of
time-based releases. I know the 4.0 release timeline was far longer
that we wanted it to be, and indeed quite difficult, I am hoping that
things become far easier now that licensing stuff is remedied.

For the record I am against feature-based releases.


View raw message