Hello Again Josh,

> The goals of my post were as follows:
> - to establish clearly that compatibility is not the only thing that  
> the community cares about (it also cares about "progress")
> - to determine whether Keith acknowledges this fact

We were clearly told by the board years ago, that stella-progress was  
going to come in Squeak 5.0.
In fact squeak 5.0 would have more progress than you could shake a  
stick at. They were so confident of this fact that at one point they  
cancelled 3.x development altogether.

It is common for open source projects to maintain two branches, the  
red/blue pills, the blue/pink planes etc.

Squeak 5.0 is the place for progress, 3.x is the place for stability.  
Simple as.

So as an application developer, I don't want progress that does  
anything at all to rock the boat, I want stability  increases and  
speed improvements month on month that is all. Anything else is not  
progress, its a pain in the rear.

Fonts and traits I can do without. I have nothing against progress  
that has been thought about, and tested fully and is optional for me  
to load. (its called a package, every innovation can be delivered as a  
package, even a changeset can be delivered as a loadable package)

Every innovation in the "3.x stable plane" should be developed,  
tested, COMPLETELY FINISHED and made loadable into 3.10 (and 3.9)  
since they are practically the same, so that all legacy code in 3.10  
and 3.9 continues to work and there are no surprises.

"trunk" is the pursuit of random "progress", on the fly, hacking,  
without thinking in advance, and without making the knowledge  
available in a usable form for anyone who is not in the "trunk" fork,  
and without a continuous testing framework. Trunk is purposefully a  
fork away from (3.9 and 3.10) And I cant tell my clients what is  
coming in 1 months time let alone a years time.

If you want progress without compatability, go and nag Craig, who said  
he would deliver Squeak 5.0 18 months ago. Andreas should have  
supported, worked with and annoyed Craig, not me. All of "trunk"  
effort should be producing 5.x on top of spoon, not 3.x.

> - to determine whether Keith acknowledges this fact
> - if so, to determine whether his approach may address the issue in  
> some way that I missed

So yes I think you missed the point of my belief that we are supposed  
to be supporting squeak as a professional development product with a  
professional attitude.

Currently the attitude is, release the image, forget about it, and  
move on to the next release, which will probably not be compatible  
with the previous one, and definitely will not have a migration path  
for you, sure we might fix some stuff but if you want to use it, you  
have to take all the pain of keeping up.

3.10 as a release should be a stable supported release, with fixes and  
improvements that do not break compatibility or continuity in 3.11  
3.12 etc etc. The 3.x team is responsible for providing 3.x-1 users a  
migration path, and the easiest way to achieve this is to make all 3.x- 
innovations, optional loads into 3.x-1. Its not hard, its just a  
matter of making the choice not to group-hack.

So when a professional developer starts using 3.10, he is continuously  
supported, with bug fixes, managed in a bug fix database, and new  
versions, all of which maintain compatibility.

So the board's first responsibility is to support the existing users  
of squeak, by making sure that the maintained version is maintained,  
and "progress" occurs within the capabilities of the existing users. I  
do not have the ability to load closures into 3.10 on my own, this is  
a serious issue. By not insisting that closures are loadable into a  
raw 3.10 the board is letting me down.

Secondly they want to make a brand shiny new product, to attract new  
users with new flashy capabilities. However, it is absolutely stupid  
to use one as a club to kill the other.

Given that the "trunk" is not providing the migration path, it is a  
year away form being ready for me to use, and there is no ongoing  
support for me as a 3.10 user. I am very concerned that squeak was a  
bad choice to make as a development tool, that I had the cheek to sit  
in meetings with clients and say, its ok, we can develop stuff and it  
will keep going for years to come.

Keith


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100124/fb48e100/attachment.htm