On Nov 9, 2012, at 10:42 PM, David Nalley <da...@gnsa.us> wrote: > 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. > > --David
I am no release expert, but I was at couple devops events lately and the continuous delivery model makes sense to me. We should aim to be able to release "every day". Automate everything up to the actual vote. The manual vote should actually be the lengthiest process in the release. With that concept, aiming at a release every week would be the optimal (I know this is silly !!) A search on Release early, release often leads to http://www.catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html , nice quick read. In general I think we should release first and fix later, rather than fix and release. Have we cut 4.0.1 yet ? I will go back to my guinness now :) -Sebastien
