>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.
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 >>
