Dan Ingalls wrote:
[............]
> Sometimes I get too busy to issue updates.  Most often, though, I am
> actively planning how to shield the less adventurous citizens of
> SqueakVille from the effects of dangerous and incomplete cycles of
> change.  There have been a couple of times since the last release when I
> could have issued updates with some confidence, but they happened also
> to be times when I was busy.
[............]
> > What's worse is that the Disney team have their own internal update stream
> > that we are not privy to. Recently, this resulted in a lot of duplicated
> > effort by people on the list, fixing a bug that was already well and truly
> > fixed. Now I realise that the Disney team are probaby working flat out on
> 
> While I dislike the pejorative allusion of the term "privy", I have to
> agree that this is a problem.  Fortunately I think there is a simple
> solution.  In the past we have been reluctant to release updates at
> various junctures, in order to shield newbies from possible
> instabilities.  What SHOULD happen is this:  when we have that feeling,
> that is when we should declare a new version number.  Newbies would not
> "see" any later updates, but any serious Squeaker could advance his
> version and track the latest changes.  We at Squeak central can freely
> broadcast everything hot off the press, knowing that only the
> self-professed test pilots will be affected.  All the necessary
> mechanism is already present in the update system.

I like this suggestion a lot. The FreeBSD project uses a set of terms we
could adapt rather nicely to cover just this sort of structure. I will
use the terms as we could use them (the exact FreeBSD definitions are
close but not quite the same). CURRENT: the latest, hot off the press
code -- perhaps minimally tested or only tested in a limited fashion;
this is where new subsystems are introduced, where new code is tried
out; may go through several minor version numbers in the process; whole
portions of the system can change in wholesale fashion; portions may
actually be broken temporarily from time to time [what you get depends
on when you grab it]. Of course, Squeak Central might not want _quite_
that much of a bleeding edge CURRENT version -- but the understanding
would be that things can get excessively interesting from time to time
in the CURRENT path. STABLE: what CURRENT becomes as feature sets
stabilize and biting bugs are smacked -- somewhere along the version
scale between alpha and beta designation - updates are primarily to fix
bugs with only minor enhancements or new features; feature set is
essentially fixed. RELEASE: what STABLE becomes after a bit of time and
use and bug fixing and polishing - should only see minor bug fixes
released; feature set is fixed.

Thus we could have (for example) a Squeak v3.0-CURRENT, a Squeak
v2.6-STABLE, and of course Squeak v2.4c-RELEASE. 

I think a number of us would *love* to be able to truly keep current
with the update stream and have a little input into (or at least
knowledge of) what is being done. The Squeak Team gets more eyes to look
at their code, more people to hammer on it to find bugs even earlier,
contributed bug fixes, people to do some of those additional little
things that you would like done but cannot find the time.... It would
also create a tighter sense of communication between Squeak Central and
the rest of us - we will know which way the wind is blowing and be able
to either adjust to it or express our reservations rather than have
essentially complete subsystems dropped in our laps that we never knew
were in the works. Some of Squeak Central's TODO items might get done by
other interested parties, if they were aware of what some of your TODO
items are.

Just some thoughts.

-- Dwight