On 23 Feb 2008, at 20:23, A.D.F. wrote: > "A.D.F." wrote: >> Alvaro Lopez Ortega wrote: >>> On 23 Feb 2008, at 14:16, Miguel Angel Ajo Pelayo wrote: >>> >>>> What do you think about that idea? >>>> >>>> 0.6.0 makes cherokee look like an immature software, and stops many >>>> people from using it. >>>> >>>> A 1.0.0 would describe more clearly that it is a mature piece of >>>> software (it really is), although it wouldn't >>>> have all the features planned for the original 1.0.0 which are not >>>> necessary for everyone. >> >> I think that 0.6.x should be a test series before doing other >> important improvements to Cherokee, so from my point of view >> it is good that Cherokee hasn't gained version 0.9 or 1.0 yet. >> >>> It is a very interesting suggestion, actually. In fact, it kind of >>> makes sense to me. >>> >>> On the one hand, bumping to higher release number would change the >>> perception of some people, and that is a good thing. On the other >>> hand, it would be kind of weird to introduce the change, and that >>> does >>> not sound like a smart thing to do. >>> >>> There might be a third option though. What if we release trunk as >>> something 'done but not quite dusted' (thinking of cherokee-admin)? >>> For instance, we release trunk next week as 0.99.0, and we focus on >>> maintaining it for a few weeks before we branch it to stable. >>> Then, we >>> could release it as 1.0 and start working on - let's call it - >>> 'Cherokee next'. >>> >>> What would you think of that? >> >> I think that Cherokee needs at least other two major versions >> before thinking to switch to 1.0. >> -------------------------------- >> >> So, I would keep the 0.6.x numeration, trying to release 0.6.0 >> as soon as possible (i.e. within a week or so); >> 0.6.x could be maintained for a while (i.e. 5-6 months); >> every improvement written for trunk/admin could be backported >> from trunk to 0.6.x as is, whereas only severe bugs (security, etc.) >> should be applied to 0.6 branch. >> >> Within 6 or 7 months we could release version 0.9 >> and then after more tests, when 0.9.x is declared really stable >> and stunning we could refine all the other parts (i.e. >> documentation, etc.) >> and switch to 1.0.0 stable. > > 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. -- Greetings, alo. http://www.alobbs.com/ _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
