I guess this was intended to go to the squeak-dev list.

On Fri, 17 Oct 2014, Eliot Miranda wrote:

> Hi Levente,
>
> On Oct 17, 2014, at 5:40 AM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Thu, 16 Oct 2014, Eliot Miranda wrote:
>>
>>> Hi All,
>>>     finally the Spur Squeak trunk image is updateable.  The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can
>>> be updated independently of the non-Spur trunk.  Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear).  Without wanting to appear too overconfident the Spur
>>> system looks to be ready for use apart from image segments (which I hope to have working some time next month).  I'm really interested in having this stress tested by as many people as possible.  Spur really
>>> does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability.
>>
>> Great news.
>>
>>> Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon.
>>> As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future.  Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is
>>> done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive.  I also auto-edit trunk configurations (the part of the image update scheme that ensures
>>> packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms.  This at east means that Spur can keep up with trunk.  But it does
>>> /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk.  Note that apart from these packages, one /can/ safely commit
>>> any other package from a Spur image to trunk.
>>> Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0).  This isn't my preference.  I'd like to see just Spur released, once
>>> reliability is verified.  But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse).  The issue is of course that we have this tricky
>>> package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to
>>> be practicable.  Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync.
>>
>> How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time?
>> This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only.
>> Then any changes could be backported manually to the future squeak46 repository if needed.
>
> Works for me.  Good idea!  Objections?
>
>
>> Levente
>>
>>> --
>>> best,Eliot
>
> Eliot (phone)
>