> -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Friday, November 09, 2012 1:42 PM > To: cloudstack-dev@incubator.apache.org > Cc: Rohit Yadav; chip.child...@sungard.com Childers > Subject: Re: [DISCUSS] releases going forward > > On Fri, Nov 9, 2012 at 3:56 PM, Alex Huang <alex.hu...@citrix.com> wrote: > > > > > >> -----Original Message----- > >> From: Rohit Yadav > >> Sent: Wednesday, November 07, 2012 9:23 PM > >> To: cloudstack-dev@incubator.apache.org > >> Cc: Alex Huang; chip.child...@sungard.com Childers > >> Subject: Re: [DISCUSS] releases going forward > >> > >> > >> On 08-Nov-2012, at 5:52 AM, Caleb Call <calebc...@me.com> 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.
None of the stuff I said are features so we're not pulling that back into the discussion. I like quicker releases but to do that it right now means we're fighting the release each time. Maybe we can limit that scope. For example, we put in the things missed in the first release along with build changes. But this time, all things checked in must come with unit tests and docs before it is committed. --Alex
