+1 I don't know about the alpha, I think we just consider the trunk alpha at freeze.
This first round we probably need to focus on automated testing during "alpha". We might want to have some automation target on the schedule (e.g. 1/20) for basic forward + reverse load and coverage automated test w/performance regression tests... I mean the framework and some basic placeholders so we can have the discussion/setup out of the way and add meaningful tests during alpha so we can have some measure of confidence when we release.... comments? john On 12/16/2009 10:13 AM, Leif Hedstrom wrote: > Bryan and I were talking about trying to come up with some preliminary > release schedule. One thing we'd like to aim for (at least initially) > is to do a "major" release every 6 months, similar to how the Fedora > projects plans their releases. I also think it'd be a good idea (going > forward) to use the versioning scheme used by HTTPD, i.e. even > releases are public releases, while odd releases are "beta" or test > releases (similar to how Linux used to do it). > > So, for this first release, we're thinking something like this: > > 1/20: Trunk is frozen and we branch for the 2.0 release > 1/25-26: Hackathon, focusing on stability (make it releasable) > 2/10: (maybe?) 2.0a (alpha/test) release. > 2/20: 2.0 Release. > > > (we'd adjust as necessary of course as we get closer). > > > I know it's short between the "alpha" and final release, but I'm not > sure we'll even need the alpha release (not sure anyone would use/test > it?). After this, we do 2.0.1, 2.0.2 releases as necessary, and then > aim for a Q3 release of 2.2 (which will have all the new features for > cache partitions etc.). In between, we'll make 2.1.x releases as we > add new features, for testing. Going forward, we'd continue to aim for > Q1 / Q3 major releases. > > Thoughts? > > -- leif >
