On Jan 25, 2010, at 5:27 PM, keith wrote:

>> I contend that for the latter, it does not matter how the fixed-point image was created, just that you continuously build and test your application against frequent releases, and work with the community to quickly fix any compatibility issues that arise.  Isn't this true?
>> 
>> Thanks,
>> Josh
> 
> It would be lovely, but it just doesn't happen. Ask etoys, cobalt, sophie, gjallar. They all started large projects and did not find the time or the effort to track subsequent squeak releases. One problem is that individual releases were too revolutionary for many, trying to to do much in one go,  this can be helped by release early and often.


Right, I completely agree with this.  That's a good think about bi-monthly trunk images, no?


> More than that the release teams didn't take any responsibility for the migration path.  (e.g. Smalltalk -> SmalltalkImage)


Please, don't get me started on SmalltalkImage.  :-)

Actually, I'm glad you mentioned it, because it highlights how the attitude of current contributors has evolved (you can trust me on this, or take an honest look at the discussions over the past months).  Making a similar change (i.e. one that breaks existing code with no demonstrable benefit except being "cleaner") would be strongly frowned upon today.  In fact, there is even skepticism about changes that don't break anything, but are only cosmetic improvements.  The reason for this change in attitude is precisely because of a concern for the migration path.  Yet another example where things might not be as bad as you've convinced yourself that they are :-)

BTW, I don't mean to disparage the efforts of the 3.9 team.  I think that SmalltalkImage was an ugly mistake, but I appreciate all of the energy they put into moving Squeak forward... and sometimes sideways ;-)

Cheers,
Josh



> 
> This same problem occurs at a package level too. I am stuck about 150 (or more now) revisions behind in Pier, because my modifications to pier (which I do keep in a separate package), are effectively (but accidentally) a fork. In trying to solve the problem, the more I see the tools, i.e. Monticello as part of the problem. However at present the solution alludes me.
> 
> K.
> 

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