I was hoping to make a release now-ish, mainly because I think the cache and protocols stuff will be a little more destabilizing than the changes made so far. It would simply provide a somewhat stable baseline for use/testing while HEAD moves on.
I was going to call it 4.99.0, I wasn't going to make any public announcements to Freshmeat or anything. A tarball would be cut and added to the file downloads section. CVS would be tagged. How about it? Regarding a final release, I agree a lot more needs to be done. The protocols stuff would be a defining feature. Docs are required. If we want other people to use it some kind of website will be needed, too. I don't know how long any of this will take. Periodic snapshots seem like a good idea. On Apr 10, 2005 3:58 AM, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 10.04.2005 um 03:05 schrieb Vlad Seryakov: > > > Do we have any plans to release Naviserver? > > > > IMHO, we still need to resolve nscache, virtual and protocol RFEs but > > even without them Naviserver is very and looks much better than AS > > already. > > Not that i am competing but i am switching to NS whenever possible > > already and what can be better proof than that :-)) > > > > I am glad that i am on that project with you guys. > > Hey, not that fast. I do not think it is necessary to hurry at this > moment. > I would really consider having (whatever) multiprotocol support, nscache > and (perhaps) ttrace accepted and loaded. We are still using the AS for > the > product that we ship and I have yet to verify that all is working fine > with > the NS as well. > > The other issue is the documentation. I'm in contact with Andreas > Kupries > from the Tcl project who wrote doctools. I would like to make him do > some > changes to doctools so we can get a nice-looking man-pages as Tcl > project > has. If you look at, for example, "man Tcl_GetStringResult" this is the > output I'm heading at. > Doctools are very good for documenting Tcl code. There is nothing to be > done extra there. The entire tcllib is documented with doctools. There > is > however a problem when you like to document C-level code this way. You > can > do it on per-call basis, so each C-function receives a special manpage, > but > I'd like to have this improved and be able to document many calls > withing > one manpage as usually done elsewhere. At this point, doctools still > would > need some changes. > After this question (doctools yes/no and if not, then what) is resolved > I > could start collecting what's outthere in respect to the documentation. > I see this as a very important step since we've been doing functional > additions > on a weekly basis. It will slip out of the control and we will not know > what > is already in the code after some time. Therefore I consider having > (anykind of) > docs very important. > > Zoran
