Hi Blake,

Having a version number of zero point anything sends a message that the application is not yet meant for real, production use.  I see ABCL as being sufficiently complete and reliable as to warrant a 1.0 release.  Enhancements and bug fixes will likely go on indefinitely. The question is, is ABCL sufficiently complete and reliable to be called Common Lisp and used in a production environment?  If the answer is yes I think a version 1.0 is due.  If the answer is no, what are the steps necessary to get it there?

When we took over from Peter Graves (late 2008) we discussed which goals to achieve. Even back then ABCL was rather stable, even though it was failing hundreds of ANSI tests and couldn't even run Maxima.

The goals we set back then were:

1. A high-quality Common Lisp implementation - which would be called 1.0 - defined by the following criteria: a. Feature complete w.r.t. CLHS b. Support for some regularly supported features, minimally requiring Gray streams (many Edi packages depend on them) 2. A CL implementation with (full) AMOP support - to be called 2.0

Note that we never defined (1.a) to be without bugs. The only thing we're lacking at this point with respect to (1.a) is that our DEFINE-METHOD-COMBINATION support is still experimental. I'm not aware that we're lacking any other (required) features.

With respect to (1.b) I'd like to note that I think our Gray streams support works most of the time, but has got some fundamental flaws we have started to address, but never completed. The issue here is that our internals are not correctly set up to handle generic CLOS objects as stream objects: they'll only handle our existing Java-stream-wrapping-LispObject-derived-Stream's.

We have defined "being a high quality Common Lisp" as being able to run many of the readily available software; some examples:

* Being able to be a build-host for SBCL * Being able to run Maxima's test suite * Being able to run CL-BENCH

And with the advent of Quicklisp (http://quicklisp.org/), I'd like to add

* Being able to compile the top 30 downloads from quicklisp (found here: http://xach.com/tmp/downloads.txt) [Note that personally I find "being able to compile" not a very high bar, though, it's a start.]

Talking to others about ABCL, I find that a high quality CL implementation is probably also defined by the documentation that's available for it - meaning that I think we should probably write more documentation for ABCL if we really want to reach huge levels of attractiveness.

The releases we have seen so far are mostly working toward the goals formulated above. At the same time, we have been working on other important goals, though, such as: * making embedding easier * increasing general stability of ABCL * specifically, increase stability under multithreading circumstances * fixing CLHS conformance issues * improving user experience

I know the zero-dot numbers are really low and giving the wrong signal. However, I hope that the fact that we release bi-monthly with significant change lists does counter that a bit. The same goes for our list of testimonials.

Yesterday, I talked to Ville on IRC (irc://chat.freenode.net/#abcl) and we agreed that ABCL being an SBCL buildhost would be a good goal to put back on the agenda for 0.26 (and possibly beyond). ABCL used to be able to build SBCL many moons ago, but unfortunately, that's no longer the case due to changes in SBCL which expose issues in ABCL.

What's your reaction to the above? Does it sound like a plan?

I didn't see a "Roadmap" link on the ABCL page.  That would be great.

Thanks for your comments. It's the easiest start for documentation that we can make. I'll definitely rewrite the above into such a page. The page to be created will reference our 'bug fixing planning page' [http://trac.common-lisp.net/armedbear/roadmap] too, btw. You may want to check it out, if you're not familiar with it.

Bye,

Erik.