I wouldn't mind doing the April/May release because of the things which are not going to make it into this release: the cache partition stuff, large document support, efficient Range support, the event system work for libev/libevent.
All of these I expect to have into the dev line in Jan, so that still gives them 6 months to bake. For a lot of applications, large object support alone is a dealbreaker, so I'd hate to delay that too long. Right now a 50 MB file (which is not that big) is broken into over 1500 pieces, each of which requires a seek to retrive, tying up an entire disk for perhaps 8 seconds (assuming cache miss). Basically the current code is unusable for anything of even moderate size. john On 12/16/2009 3:13 PM, Bryan Call wrote: > On 12/16/2009 10:52 AM, Paul Querna wrote: >> On Wed, Dec 16, 2009 at 10:13 AM, Leif Hedstrom<zw...@apache.org> >> 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. >>> >> +1 in general, I think this largely makes sense and is a good plan, >> though I have my doubts about a 10 day gap between alpha and a stable >> release, but we can see how quickly it goes when we get there :) >> >> Thanks, >> >> Paul >> > We have been talking about making the 6 month release around April/May > and another around October/November. It would be ruffly 6 months > apart and we release in the fall before everyone starts to take vacation. > > We don't know yet if we would have a release this April/May because we > are releasing in Feb/March this year. > > -Bryan
