4.2 next steps

We should wrap up on putting new features into the trunk now so we can
focus on applying final fixes and getting 4.2 out the door.

We need volunteers for these items:

[ ] Build a 4.2alpha trunk image, upload to ftp.squeak.org.  We can
work from this base until final release.

[ ] Review and clean the Inbox; merge things that should be, remove
things that shouldn't, leave items that should be left for further
consideration.

[ ] Mantis bugs:  Do we have any bugs on Mantis critical for 4.2?

[ ] Release notes:  Who will put together 4.2 release notes?

[ ] Welcome message and showcase projects?

[ ] Create a 4.2 release repository on source.squeak.org we can use to
backport future fixes.

[ ] Make all tests green.

[ ] Do we need a new ReleaseBuilder method / subclass?  How does
SystemVersion get updated?

[ ] Coordination with the new VM; we just need to make sure any
image-items needed for the new VM's are present.


We can get all of this done in 2010 if we will each volunteer for
something.  Early volunteers get to choose which items they prefer to
work on by stating so here.  :)

 - Chris

If the good people of Squeak can give me a list of doIts to run on the image after pulling down the updates (can't find the list I made anywhere,) I can roll up a new trunk image and push it up to the FTP server tonight or tomorrow.

I told Hannes I'd do this a month ago but got inundated with work: sorry for dropping the ball Hannes.

On Dec 13, 2010, at 8:54 AM, Chris Muller <[hidden email]> wrote:

On Mon, 13 Dec 2010, Casey Ransberger wrote:

> If the good people of Squeak can give me a list of doIts to run on the image after pulling down the updates (can't find the list I made anywhere,) I can roll up a new trunk image and push it up to the FTP server tonight or tomorrow.

I think you should only evaluate this after updating the image:

Smalltalk cleanUp: false.


Levente

Am 13.12.2010 um 20:01 schrieb Levente Uzonyi:
> On Mon, 13 Dec 2010, Casey Ransberger wrote:
>> If the good people of Squeak can give me a list of doIts to run on the image after pulling down the updates (can't find the list I made anywhere,) I can roll up a new trunk image and push it up to the FTP server tonight or tomorrow.
>
> I think you should only evaluate this after updating the image:
>
> Smalltalk cleanUp: false.

Shouldn't we call the following as well?
ReleaseBuilderTrunk prepareNewBuild

May I suggest that we add the following there before?
MCWorkingCopy flushObsoletePackageInfos

Bert argued we should do it during the release. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/154868.html

Cheers,
Bernhard

On Mon, 13 Dec 2010, Bernhard Pieber wrote:

No, ReleaseBuilder* should be removed from the image IMHO.

>
> May I suggest that we add the following there before?
> MCWorkingCopy flushObsoletePackageInfos
>
> Bert argued we should do it during the release. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/154868.html

The release is a bit different. In that case we will do
Smalltalk cleanUp: true.


Levente

>
> Cheers,
> Bernhard
>
>
>
>

Am 13.12.2010 um 22:56 schrieb Levente Uzonyi:
>> Shouldn't we call the following as well?
>> ReleaseBuilderTrunk prepareNewBuild
>
> No, ReleaseBuilder* should be removed from the image IMHO.
There is a lot of cruft there which should be cleaned. Shouldn't the code for creating new trunk images for uploading to ftp.squeak.org be in the trunk image so that everyone can test and do it? Why not?

Where would you keep the code for preparing the release? In a different class or completely outside the trunk?

>> May I suggest that we add the following there before?
>> MCWorkingCopy flushObsoletePackageInfos
>>
>> Bert argued we should do it during the release. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/154868.html
>
> The release is a bit different. In that case we will do
> Smalltalk cleanUp: true.
So you mean, this is not the release yet and therefore it is not done yet? Or should MCWorkingCopy flushObsoletePackageInfos not be done at all in your opinion?

Curiously,
Bernhard

On Mon, 13 Dec 2010, Bernhard Pieber wrote:

> Am 13.12.2010 um 22:56 schrieb Levente Uzonyi:
>>> Shouldn't we call the following as well?
>>> ReleaseBuilderTrunk prepareNewBuild
>>
>> No, ReleaseBuilder* should be removed from the image IMHO.
> There is a lot of cruft there which should be cleaned. Shouldn't the code for creating new trunk images for uploading to ftp.squeak.org be in the trunk image so that everyone can test and do it? Why not?
>
> Where would you keep the code for preparing the release? In a different class or completely outside the trunk?

In Squeak 4.1's release process ReleaseBuilder was not used. It was an
improvement of Squeak 4.1 that you can evaluate

Smalltalk cleanUp: false
or
Smalltalk cleanUp

to empty caches and free up some space and evaluate

Smalltalk cleanUp: true

to prepare the image for release. So the code is in the image, but there's
no central place for such code.

The ReleaseBuilder and ScriptLoader packages were only kept, because they
may contain useful information to enhance the release process. We should
review them, move the useful code to #cleanUp: methods, then get rid of
these packages.

>
>>> May I suggest that we add the following there before?
>>> MCWorkingCopy flushObsoletePackageInfos
>>>
>>> Bert argued we should do it during the release. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-November/154868.html
>>
>> The release is a bit different. In that case we will do
>> Smalltalk cleanUp: true.
> So you mean, this is not the release yet and therefore it is not done yet? Or should MCWorkingCopy flushObsoletePackageInfos not be done at all in your opinion?

Exactly, this will be a beta.


Levente

>
> Curiously,
> Bernhard
>

Hey cool, even I can remember that:P I really like how it's just one thing to have to run. I'll probably continue to really like how it's just the one the thing to have to run for as long as I remain the community CI-server er hum:) I wonder how the Hudson effort is coming along...

Now I got it. Thanks for the explanation. I just saved Monticello-bp.413.mcz in the inbox which puts flushObsoletePackageInfos into a cleanUp: method.

I agree with Bernhard, it seems appropriate for there to be a place
that can boostrap new Squeak versions from the prior ones..?

#cleanUp: is a separate issue from ReleaseBuilder isn't it?  There may
be other things to do besides "clean-up", so maybe ReleaseBuilder is a
good place for those kinds of things?  For example, update
SystemVersion from '4.1' to '4.2'.

 - Chris