>--- "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>
>>  Nothing compels anyone to use the alpha development versions.  There
>>  has a been a stable squeak (2.8) for quite some time.
>
>Good point, Andrew. But -- and I allow for the possibility, even the
>probability that I'm missing something very central here -- it isn't clear to
>me that anyone is fixing bugs in 2.8 (assuming there are any) or that there's
>any obvious way to add the cool new 3.x stuff into a 2.8 image. This includes
>most if not all of the modularization stuff that I think we really 
>need to have
>to make forward progress a seriously feasible undertaking for anyone 
>other than
>SqueakC and a handful of other insiders.

Be patient.  2.8 is stable.  Updates and patches WERE backpatched for 
a brief time.  Now direction is moving on to 3.X, which in time will 
replace 2.8 as the stable version of Squeak.

I am reminded of the FreeBSD shift from 2.2.7 to 2.3.X and, then to 
2.4.  Many commercial products stuck with 2.2.7 during the 2.3 
"development era," and migrated to 2.4 or a late 2.3 during that time.

The difference between commercial products and open source, is that 
the unexpurgated output of interim versions and development are 
constantly available.  These developments unsurprisingly include 
fixes that some "holdbacks" would like to see backpatched to earlier 
versions.  Guess what?  THEY OFTEN CAN BE!

Having recently served as V.P./R&D for a public company that 
developed from an open source platform, I know this strategy to be 
quite common.  I can attest that the precise problem with forking a 
"stable" version for commercial purposes is that you render your 
product incompatible with future developments.  A narrow-minded view 
toward stability reminds me of the proverb about "a simple 
consistency being the hobgoblin" of a developer's mind.

I suggest that if you need to "get it out the door," you probably 
should, as I have done, choose a stable version and abandon updates 
and upgrades except those  patches you yourself wish to support. 
Then, as soon as possible, get your code back up to current.  Build 
yourself a framework to protect yourself from massive sea changes, so 
that the framework need only be slightly modified to acommodate 
underlying system changes, if you must.

In short, I simply don't see any problem with Squeak's stability that 
would give pause to any serious developer.  EVERY version that has 
reached solid release status has bugs.  Guess what?  ALL SOFTWARE HAS 
BUGS.  But every version since I have been involved with Squeak has 
been remarkably stable, or trivially patched where it has hiccupped.

Perhaps you ought to hang out for awhile longer, and at least try to 
contribute your modifications, before proposing a fork.  Forks should 
be the result of irreconcilable differences, and never one of mere 
convenience.