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