That road map makes much more sense than the initial 1.0 idea, speeding up the process to a "1.0" version but also making important improvements that are still missing.
2008/2/23, A.D.F. <[EMAIL PROTECTED]>: > > Alvaro Lopez Ortega wrote: > > > > On 23 Feb 2008, at 20:23, A.D.F. wrote: > > > > > > > If you want to mark the distance between 0.5.x and current trunk, > > > next branch could be named 0.8 (after relicensing it), > > > so that in 0.9 we could add some of the planned steps for old 0.7 TODO > > > along with new ones: > > > > > > [ ] Dtrace hooks > > > [ ] priv.h on Solaris > > > [ ] New header entry > > > [ ] Generic caching (HTTP-Cache) > > > [ ] Mime encodings separated from mime types > > > [ ] Chuncked encoding > > > > > > [ ] flexible internal error reporting to syslog too, etc; > > > [ ] full signal handling; > > > [ ] HTTP/1.0 speed up; > > > [ ] HTTP/1.1 pipelining speed up; > > > [ ] sendfilev() support > > > [ ] more I/O parameters; > > > [ ] sophisticated file cacheing. > > > > > > The following ones could be added after 1.0 is released, > > > i.e. in 1.1 or 1.2, unless someone contributes and > > > donates the source code within the end of 2008: > > > > > > [ ] X-Sendfile > > > [ ] WSGI handler > > > [ ] AJPv13 handler > > > [ ] WebDAV handler > > > [ ] Upload progress module > > > [ ] mod_evasive > > > [ ] Memcached support > > > [ ] Language support (handler?) > > > > > > The following ones could be added in 2.0: > > > > > > [ ] AIO based fdpoll > > > [ ] splice() support > > > > It does also make sense to me. However, I would reduce the new feature > > number in 0.8 and 0.9 to de minimum. In my opinion, a good roadmap > > would be: > > > > 0.8.0 > > ----- > > [ ] New header entry > > [ ] Mime encodings separated from mime types > > [ ] Chuncked encoding > > > > 0.9.0 > > ----- > > [ ] full signal handling > > [ ] flexible internal error reporting (to syslog?) > > [ ] HTTP/1.0 speed up (not high priority) > > [ ] HTTP/1.1 pipelining speed up (not high priority) > > > > I would postpone the rest to 1.0 or later, actually. In fact, these > > improvements should not take us much time and we could release 1.0 > > within... a couple of months? > > > > I think that bumping to a 1.0 release as soon as possible is a good > > thing. But, even more important than reaching the 1.0 milestone soon, > > is to release new versions often. > > > OK, I meant that 0.8.0 could be the next upcoming release > (now 0.6.0 in trunk). > > I agree with you that removing new features > and speeding up release process towards 1.0 > (in order to release 1.0 within 4-5 months) > would be a very good thing. > > > -- > Nick Name: A.D.F. > E-Mail: <adefacc () tin ! it> > E-Mail-Format: Plain Text only (please); view using font Courier New > -- >
_______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
