Is there a plan to spin out Squeak (the ST VM) from Squeak (the image) 
in this (or subsequent) release cycle? or will the two releases go 
hand-in-hand forever?

Now that the same VM is used by multiple (image) projects like Scratch, 
Etoys, Pharo, Cuis and with binary variants like 32bit/64bit, cog/spur 
etc. putting the VM on a separate cycle may be easier than linking it 
with Squeak project releases. The VM may continue ship with a built-in 
image for bootstrapping other images or for VMMaker but that need not be 
linked with the latest Squeak release.

Regards .. Subbu

On Thursday 01 March 2018 11:27 PM, Eliot Miranda wrote:
> Hi All,
> 
>      we're moving close to a new Squeak release.  There are some issues 
> to discuss before we decide  exactly what and when to release.  I have 
> two issues that I would like people's opinions on.
> 
> 1. the VM can be compiled with support for read-only objects, and indeed 
> Pharo is already doing this.  Were we to enable read-only object support 
> we could introduce read-only bindings.  I have this code ready to go, 
> but the current Squeak VM does not include read-only object support.  We 
> could go ahead and release without read-only object support or enable 
> read-only object support in the VM, push the new VMs out and enable 
> read-only literals.  It would then take a few days for everyone to test 
> their code and fix issues with read-only literals.  For example, code 
> such as
> 
> a := { 'one ' . 'two ' . 'three ' }.
> a do: [:e | e at: e size put: (Character value: 0)].
> 
> must be rewritten, e.g. as
> 
> a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll: 
> Character space asString with: Character null asString].
> 
> and the classic
> 
> '' writeStream
> 
> as
> 
> '' copy writeStream
> 
> i.e. literals are read-only but copies of literals are not.
> 
> 2. the current VM, Monticello and the ClassBuilder has full support for 
> ephemerons, which provide instance based finalization. For example, if a 
> file that is the key of some ephemeron in a registration dictionary, 
> then, with a suitable finalization process, the VM will arrange that the 
> ephemeron gets sent finalize when the file is only referenced from 
> ephemeris, and then the ephemeron can finalize the file itself, flushing 
> any buffered characters and closing the file's descriptor. What we have 
> now is a copy of the file in a weak registry, which means we finalize 
> the copy not the actual file. This limits our ability to write clean 
> file implementations. The same applies to several other uses of weak 
> registries. Again Pharo is using the facility (and hence we can use 
> their finalization process and some of their code).
> 
> So the question is should we hold up the release for these features or 
> should we go ahead and somehow arrange that we do address these (and 
> other?) issues promptly in a subsequent release?
> 
> Let me make a proposal. We go ahead and make a release with what we 
> have, calling it Squeak 5.5, and then follow a plan to provide read-only 
> object support, read-only literals, and as mush of the 
> finalizationsystem rewritten to use ephemeron (where appropriate) as we 
> can manage by, say, September 1. This will be Squeak 6. And the trunk 
> process would update to requiring a rad-only-object enabled VM 
> immediately after the 5.5 release.
> 
> _,,,^..^,,,_
> best, Eliot
> 
> 
>