Hi All,

I was looking for the written summary of what the current Release process 
looks like, but I couldn't find any.
So, I was wondering what the current Release process looks like, and what 
the role of the Release manager is.
I have a vague idea about these, but it would be nice to have a checklist 
at least.

Levente

On Thu, 1 Mar 2018, David T. Lewis wrote:

> According to our web site, the current release is Squeak 5.1, and trunk
> is Squeak 6.0alpha.
>
> I think it has been about a year since the last official release, and
> a lot of great stuff has gone into trunk during that time. So it would
> be good to put out an official release some time soon. For that we should
> identify a person to serve as release manager to make it happen. I expect
> we will discuss this in our board meeting next week, but input (and volunteers
> or nominations) from anyone in the community would certainly be welcome.
>
> If we do something in the near term, then it would make sense to me if
> it was called Squeak 5.2. And if that happens, it would be good to incorporate
> full support for ephemerons and read only objects into whatever release
> comes next after that.
>
> In the mean time, my view would be that any changes for support of read
> only objects and ephemerons should be introduced as soon as possible
> regardless of the release schedule, just as long as this can be done
> without requiring incompatible VM changes. I'm not quite clear on whether
> that is the case here. But basically what I am trying to say is let's
> move this forward as quickly as possible. If it is a change that would
> cause pain for general users of Squeak, then hold off until after then
> next release, and let's make sure that next release happens soon.
>
> So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's
> find a release manager and make it happen.
>
> And just so we do not forget - The last release was still focused on
> 32 bit images. The 64 bit system is not longer experimental, so we need
> to publicize this better in our next release and document the limitations
> so that users are aware that they will not be able run their 64 bit image
> on a 32 bit platform.
>
> Dave
>
> On Thu, Mar 01, 2018 at 09:57:52AM -0800, 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
>
>>