As laudable a goal as a simpler/better documented image is, I think the extra work that comes with duplication of release streams will probably mean your proposal won't capture enough support.

In my 14 years in Smalltalk the only mechanism I've seen work that leads to well documented classes/messages is a rule by the image builder that a change file is ONLY accepted IF it leaves EVERY class touched by the changes FULLY documented (class + message comments). This causes a lot of cursing and swearing initially because it means to change even a single method you have to take on commenting the entire class. But its amazing how quickly the image gets documented, how much obsolete code gets found and removed, how many bugs are noted and fixed, and how quickly the system becomes more easily usable, reusable, and maintainable because the system is more understandable.

Once the classes are documented as such and a system for naming method protocols is followed, I wrote an object that traversed target classes and a produced cross-referenced HTML pages documenting the public interfaces of the classes. Being able to instantly view the commented public interface for a class immensely helped reusability and respect for the public/private interface division.

Carl Gable Watts


Maarten Maartensz wrote on 18/4/02 5:00 pm:

...I'd propose the following to both Squeak.org and the Squakfoundation:
- To maintain TWO releases as a standard policy:
    A. Developers' release 
    B. Learning & Teaching release...