The boundary between 3.10 and 3.11

Squeak Board Members:

Now seems the idea of 3.11 alpha is accepted.
But remains some questions.

I wish we could have some .cs in the updates folder as we have in previous Squeaks and mark the end of 3.10 and the begin of 3.11 on the point when this technique don’t work.

I clarify:
Taking a first Squeak 3.10.2 trunk , without any added and doing Andreas technique  I have the attached .cs.
If you have Squeak3.10.gamma.7159.image as starting point and in the same folder have a folder named “updates”, could hit Utilities applyUpdatesFromDisk. From the “do” menu.

And you see 7216 don’ complete the load raising a debugger.

So I tell this is the boundary.
We should have a 7216advance3dot10final , closing the 3.10 version and 7217Start3dot11WithTrunk

Why?

Because if not have this clear, we have the odd case of a version which could not load his own things, like the .pr files

I like Squeak Board Members opinion about this.

Edgar

P.S. I must remove the attached .cs or my mail don’t  got the list
------ End of Forwarded Message

>>>>> "Edgar" == Edgar J De Cleene <[hidden email]> writes:

Edgar> Squeak Board Members:
Edgar> Now seems the idea of 3.11 alpha is accepted.
Edgar> But remains some questions.

4.0 is right around the corner.

As in, we're very very very close to having a license-clean release.

I'm not sure there'll be a 3.11.

The patches from 3.10.2 will be applied on top of this 4.0 release
(which might be identical to 3.10.2 after condensing sources)
to make 4.1, which will be our next release after 4.0.

At least, this is how I understand it, sorta speaking with my
board hat on, but slightly tilted to one side. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On 2009-12-16, at 3:55 PM, Randal L. Schwartz wrote:

Well, we already have a downloadable image called Squeak 3.11alpha, so it's too late to avoid 3.11 entirely. I think Edgar's point stands - given a 3.10.2 image, it's possible to update it via the update stream, but only up to a certain point. We should create an endpoint to the 3.10.2 stream and point people either to 3.11alpha (which may never see beta) or 4.1.

Colin

Edgar J. De Cleene wrote:
> Taking a first Squeak 3.10.2 trunk , without any added and doing Andreas
> technique  I have the attached .cs.

It looks like you ended up not sending them. Can you email me these
change sets privately or put them in a place for download?

I'm not sure what 7216 is - possibly closure related stuff? If so, that
sounds like a good boundary. If not, allow me to have a look first to
see if we can address the problem.

Cheers,
   - Andreas

On 12/17/09 7:56 PM, "Andreas Raab" <[hidden email]> wrote:

Following private advice by Andreas:
I start with clean Squeak3.10.gamma.
Made the .cs in the order first 3.102 image load from trunk.
The point of change is

>>From update-ar.5.log
>
> ========== Compiler-ar.68 ==========
>
> Prerequiste changes for Closure installation.

So, the last of old .cs should be
7213AdvanceTo3dot10final.1.cs, included in the Tar and gz file.
Here I made a clean Squeak3.10final.7213.image , ready to put in ftp if all
agree.
The system is ready for hitting the updates button , follow actual Trunk
updates.

You only need fileIn first SystemProgressMorphGlue.1.cs (we could hide in
7214AdvanceTo3dot11)

I let the system go and seems load updates.

Edgar

Edgar J. De Cleene wrote:
Looks good. A couple of comments:

- The last update should be a *choice* to advance to 3.11, not forced.

- When the change to 3.11 is made there needs to be a BIG FAT WARNING
that a new VM is needed before further updates can be loaded.

- Some of the changes cause conflicts when updating later. I'm not sure
why that is but the need to resolve those if you really try updating
should be noted somewhere.

How about we open a workspace when changing the version to 3.11 that
says something like:

-----------------------------------------------------------------------
Your system has been set to receive updates for 3.11 and beyond. Please
note that in order to process the following updates you MUST use an
updated virtual machine available from:
- http://squeakvm.org/win32 (for Windows - use 3.11 or later)
- http://squeakvm.org/unix (for Unix - use 3.11 or later)
- http://???? (for Mac - don't recall canonical location; don't recall
required version)

In addition, you may receive some Monticello conflict warnings when you
update through 3.11. This is expected and nothing to worry about. When
you receive such a warning simply choose "All Newer" and "Merge".
-----------------------------------------------------------------------

Cheers,
   - Andreas

Andreas and all Squeakers:

Here I attach the .cs as we discuss earlier.
I do not thing any do the all way from the 7213 until we have now , because
is take hours and many hand labor.

But insist in my previous point for we have a nice close to 3dot10, and
actualize info in http://www.squeak.org/.

We should "advertise" the fact we have a new release in progress and this
release is moving fast and going apart of 3.10 was.

I preparing the Christmas version of Fun3.11, it's your chance to ask for
packages your wish have into.

Edgar

Hi Edgar -

Edgar J. De Cleene wrote:
> Here I attach the .cs as we discuss earlier.
> I do not thing any do the all way from the 7213 until we have now , because
> is take hours and many hand labor.

I think we need to make sure that this works. I'll spend some time on it
today.

> I preparing the Christmas version of Fun3.11, it's your chance to ask for
> packages your wish have into.

Sounds great. Do you want to check out Mason to see how it fits building
a larger image automatically? It would be good if we could start
automating these processes.

Cheers,
   - Andreas

Folks -

I spent some time looking at the update process from 3.10 to 3.11 and
I'm not entirely happy with the process proposed so far. There are two
independent issues here:

1) Are there fixes from 3.11 that should be backported to 3.10? If we
have fixes that 3.10 users would like to see we should set up another
maintenance release, i.e., 3.10.3 and push those out. This issue is
unrelated to updating to 3.11.

2) How do we get people from 3.10 to 3.11? From my perspective offering
an update that takes you from a known stable version (3.10) to an
unstable version (3.11alpha) feels wrong. I think this should be a
manual decision.

As a consequence, I would propose that we split the process a little: We
define another update target in the updates.list for 3.11 alpha which
contains the necessary preparations for updating to 3.11. I have
attached a change set which can be filed into any 3.10.x image and will
allow you to successfully receive trunk updates (it does take a while
though). Anyone who now wants to transform their 3.10.x image forward to
3.11 can do so by manually advancing their system version to 3.11alpha
and simply hit update (which would load the attached update first, then
continue with loading trunk updates).

This process leaves us with the options of both backporting a few more
fixes in the middle as well as issuing an automatic update to allow
advancing to 3.11 if we decide that's a useful step.

Summary:
1. Let's define a Squeak 3.11 alpha target in updates.list
2. Put in something like the attached CS as the only 3.11 update
    (this still has my timeout fix in it; might want to change this to
     Bert's solution)
3. Decide whether we have high priority fixes to backport as 3.10.3
4. Decide whether or not to offer an automatic update from 3.10 to 3.11

Cheers,
   - Andreas

Andreas Raab wrote:

On 2009-12-19, at 4:23 AM, Andreas Raab wrote:

>> I preparing the Christmas version of Fun3.11, it's your chance to ask for
>> packages your wish have into.
>
> Sounds great. Do you want to check out Mason to see how it fits building a larger image automatically? It would be good if we could start automating these processes.

I'll be happy to help with this, FWIW.

Colin