> Progress which cant be used is not actually progress.

 From my point of view, every feature of 3.11 that you publish which  
is directly loadable into 3.10, I will accept as progress, because I  
can use it now.

Otherwise, I will have to wait over a year to port my code base and  
find out.

Presently it seems to me that every feature of 3.11, is a potential  
compatibility problem, making the port more difficult and the  
probability of the port happening more unlikely.

I get paid for delivering an application that works. The porting  
process, when it eventually happens will end up as a month or so of  
unpaid work, since the client doesn't care about the details.

What I don't get is how come Randal, who is an application developer  
himself, doesn't see this.

Do you have some other solution? Ahhh I get it. Randal is building his  
stuff on other peoples packages like seaside, so you get to leave the  
hassle of fork incompatibilities to them, its "someone else's  
problem". Cool solution.

So... the seaside crew announce that they are going to solve this  
problem by only developing for Pharo, and the Magma guy announces that  
he is going to solve this problem by only developing for Squeak. Pity  
the poor soul who wants to use Seaside with Magma

that would be me

Keith

p.s. before someone who is incapable of abstract thought pipes up and  
says "but seaside runs on squeak as well", and "magma runs on pharo as  
well" The Magma-Seaside case is "only an example" demonstrating the  
principle of the problem.

p.p.s now with the current state of play, I simply despair, since  
squeak ceases to be a viable platform to actually work in, because  
everyone is insisting on developing to moving targets, and I mean  
everyone! All you have to do to change this is conceptually develop  
patches only relative to specific non moving releases. Then all of the  
forks will naturally converge their API's, and you wont leave people  
behind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100124/e6aca48c/attachment.htm