So, McCLIM is already pretty old, and while I can't claim to have worked on it for more than a year and a half, I feel like I have a pretty good grasp of what it does, and how well it does it. Perhaps we should start wondering about releasing a "stable" McCLIM, that is, one that is feature complete (with relation to the CLIM spec) and more tested than out usual releases. I'm not saying we should slap a stable version number on the 0.9.6 release, just that I think it would be a good, and achievable, goal to release a stable version this year. What would need to be done to make this happen? Here's a preliminary list, if you feel it is incomplete, please add to it:
* First, implement all the reasonable parts of the CLIM 2 spec, with the exception of things that are unimplementable, underspecified or just really hard to do properly (fully generic designs, alpha blending and all, falls in this last category, I think). Things that are underspecified should probably be implemented by looking at later CLIM specs, as well as classic CLIM behaviour. We are already mostly there. Does anyone know exactly what is missing?
* Create a better test suite, at least something that can actually be called a test suite, though it may not fully test the entire system. This is probably a must if a "stable" release is to have any meaning at all, and fortunately, many of the tricky aspects of CLIM do not actually need a graphical interface, and the Null backend may suffice for the majority of the rest. I would prefer using an actual regression testing library (such as FiveAM) compared to files filled with asserts.
* Select a number of extensions (not necessarily all of them) and make sure they're as well tested as the core CLIM functionality. These extensions should also be documented.
* Have at least one backend without major flaws. I think the CLX backend is good enough, apart from some suboptimal performance. Gtkairo may not reach that level this year.
* Insert docstrings for all exported functionality. If I recall correctly, Robert Strandh spoke with one of the original CLIM spec authors and was told not to worry about copyright issues, so we could just copy from there.
The following is what is NOT necessary for a McCLIM 2.0 release:
* Support for LispWorks and Allegro CLIM extensions.
* Fully working and tested extensions. We only need to select those that are feasible to bring up to a sufficiently high level of stability and performance (does this leave out mcclim-freetype?). Of course, we should document which ones.
* More than one fully working backend.
* Documentation covering CLIM itself. The spec will have to do for now.
Finally: when you saw this email, none of you thought "I wonder what insightful observations this thoughtful engineer has about a stable release", you thought "why is this crazy hacker talking about a 2.0 version, we're still pre-1.0!". My idea is to make the McCLIM version number follow the CLIM spec version number. While this is not terribly useful for a 2.0 release in isolation, it makes it easier to design similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions, as well as the hypothetical future CLIM 2.3 spec that will fix all the ambiguous and underspecified details and bring CLIM into the 90's.
What are your thoughts?