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