A new Squeak release

>This was the third, in the middle another escape me for picture
>But at this early point we have

>4465 run, 4384 passes, 34 expected failures, 34 failures, 13 errors, 0 unexpected passes
I>’m afraid this could not go out

     Hi, there.

the release manager has to update the release notes [1], our Website [2], and our CI infrastructure [3][4].

The release-specific in-image code can be found here:
ReleaseBuilder class >> #setPreferences
ReleaseBuilder class >> #configureDesktop
ReleaseBuilder class >> #configureTools
ReleaseBuilder class >> #releaseRepositoryName (! read only !)

You can tell the community about the different steps in the release process by running step1*-step3* messages in ReleaseBuilder (see category "manual -steps"). This basically changes the system version, which you have to communicate in a changed "ReleaseBuilder class >> #initialize" method to be committed to the Trunk repository.

Finally, after you updated the CI to produce release images automatically, reset the Trunk version again via "ReleaseBuilder class >> #step0AssureAlpha". Make up some new version like "6.5" or "7.0" ... which will be the current Alpha Trunk version from that point on. Or return to "6.0" if this release would be "5.2".

Most of the other stuff you find in the ReleaseBuilder is for local try-outs only. You can also take a look at the full Smalltalk CI script [5].

Best regards,
Marcel

[1] https://github.com/squeak-smalltalk/squeak-app/tree/squeak-trunk/release-notes
[2] https://github.com/squeak-smalltalk/squeak.org
[3] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/.travis.yml
[4] http://files.squeak.org/base/
[5] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_image.st
 

Am 06.03.2018 16:25:25 schrieb Levente Uzonyi <[hidden email]>:
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
>
>>

 

Hi all,

On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <[hidden email]> wrote:

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?

I always thought it was clear that with OpenSmalltalk release, I meant the VMs and not a new Squeak release. But it looks like people thought I was talking about a new Squeak release, thus Eliot's email I guess. Sorry for the confusion, my bad!

I do agree that there should be a new Squeak release rather sooner than later, but I am still interested in having a new checkpoint for the VMs soon. This helps us to find out how stable current Squeak VMs are and it's also useful for things like CI.

 

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.

Those are some reasons why I think it would make sense to decouple the release processes for both the vm and the image. Why couple a new vm release to a Squeak or Pharo release if we could independently make new vm releases and then dialects can use the version they want or need. Maybe, this way we can fix VMs bugs without having to prepare a new image release: treat image and vm versions independently and only say "Squeak-5.x" needs "OpenSmalltalkVM Y or later" (assuming Squeak releases happen before breaking vm changes, such as Spur support).

Best,

Fabio

 

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
>
>
>