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? Regards. > > Thanks > > On Nov 7, 2012, at 4:42 PM, Alex Huang <alex.hu...@citrix.com> wrote: > >> +1 semver >> >> +1 on 4 months as the timing. My opinion is that the more releases we'll >> do, the better we'll get at it. >> >> --Alex >> >> -----Original Message----- >> From: Marcus Sorensen [mailto:shadow...@gmail.com] >> Sent: Tuesday, November 06, 2012 11:25 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: Re: [DISCUSS] releases going forward >> >> 4 months seems like plenty when I consider the things that missed the cut >> into 4.0. I'm not sure how much the cycle will drive/kick off new >> development vs just opening a window to merge changes that may have been >> incubating any number of months, or just not lined up perfectly with the >> previous window. >> On Nov 5, 2012 2:41 PM, "David Nalley" <da...@gnsa.us> wrote: >> >>> On Mon, Nov 5, 2012 at 12:58 PM, Joe Brockmeier <j...@zonker.net> wrote: >>>> On Mon, Nov 05, 2012 at 06:34:35AM -0800, Kevin Kluge wrote: >>>>> I'd have a preference for 6 month releases. Releases are a lot of >>>>> work and I'd prefer to spread that over fewer iterations per year. >>>> >>>> Presumably, releases will be less work once we do them a few times >>>> and keep adding automation. >>>> >>>> I'm not really picky about 6-month vs. 4-month, but I just wanted to >>>> point out that future releases should be easier than this one. >>> >>> Six months seems like an eternity to me, though Kevin's point re level >>> of effort is worth acknowledging. Look at the past history of changes >>> within 6 month windows - they've been massive - if anything this >>> increases the QA burden at the end of a large development cycle, there >>> is greater surface area in which changes happen. I personally favor >>> release frequently and release often with smaller changesets. >>> Honestly the focus of the 4.0 release was largely getting the codebase >>> into shape from an ASF policy POV - but that doesn't diminish the >>> massive number of man hours invested into manually testing. IMO that's >>> not repeatable nor should we strive to make it routinely repeatable at >>> that scale. We were fortunate that the Citrix QA folks essentially >>> carved out man-weeks worth of time for us, but we can't guarantee that >>> they will equally be available to us, nor should the project be >>> dependent on them. We simply have to have automated testing that runs >>> continuously and thoroughly. The code base is too large and even to >>> people who have been hacking on it for years, it's depths are >>> occasionally unfathomable. >>> >>>> >>>>> And I would just call them all major releases (versioning aside). >>>>> I'm thinking of something like Fedora. We can independently decide >>>>> to do minor releases (presumably no features) in between the >>>>> majors. > >>>> >>>> Not sure I understand the distinction you're making here. >>>> >>>> In another thread, I think we were discussing monthly releases for >>>> minor releases. IMHO, that's a good schedule and we should try for a >>>> monthly release rather than trying to decide each one independently. (e.g. >>>> "well, do we have enough bugfixes for a point release now? How about >>>> now?" Etc.) >>> >>> I think this is far more subjective. You don't issue a bugfix release >>> if there are no bugs to fix (unlikely that there will be no bugs, but >>> there might be no bugs that are worth fixing, or that people have >>> fixed) or alternatively we may discover a bug awful enough to demand a >>> faster release and only releasing on 'patch Tuesday' isn't in >>> everyone's best interest. >>> >>> --David >>> >
