Last updated at 1:08 am UTC on 28 August 2015
This is very, very, obsolete. See VI4 for more about that.
Version 4 is expected to incorporate a number of incompatible changes to the image format, and possibly to the format of the sources and changes files. The motivation for this work includes a number of factors
Within the context of this page, the Version 4 changes are solely those related to new formats and any image-side changes to support them. It is intended that Version 4 will be produced automatically from Version 3.8 or 3.9, with no significant change to the user-level content of the parent image.
- Clean up a number of ugly patches in Version 3
- Simplify and generalize a few aspects of Version 3
- Facilitate a number of anticipated extensions to Squeak
The official distribution list for communication about this work is squeak-vmdev.
The self-appointed maintainer for this page and for periodic status reports to the wider community is Dan Ingalls.
Foremost in the set of "anticipated extensions" is compatibility with 64-bit architectures. This is, or should be, completely orthogonal to all the other changes in Version 4, but it also requires changes to the image format (for instance, 64-bit modulus in Form bitmaps). Plus Dan wants to get it done, so it's a good driving force.
For status see: (obsolete) 64-bit Squeak 2004
The scope of changes is currently under discussion.
Please refer to Version 4
The process that I propose is roughly as follows. For every change that we have decided on, we will make the corresponding change to the SystemTracer and write a new image. Then we make the corresponding changes to the Simulator and make sure that it runs. Then we emit C code and compile a new VM for at least one MSB and one LSB platform, and make sure that it runs.
While the changes will be cumulative, they always begin with the 3.7b base image. This maximizes the likelihood that, when we are ready to merge with the then-most-current Squeak release, the conversion will work the first time.
As soon as we have incorporated all the agreed-upon changes and everything works, we will prevail upon the guides to synchronize with us in a double release. The first will be a 3.7Nbeta, which is whatever the current release is, plus any fixes we need. The second will be a (hopefully) identical code release in the new format, named 4.0beta.
Task List and status
- Choose the scope of Version 4 changes
Please see Version 4
Let's try to have it all settled by 5/1
[4/5] In process – see above
- Define the Version 4 format
Follows the scope decisions
- Detailed Task List and status
Please see Version 4 DetailedTask Status
Completion is defined as the double release described under "Process" above.
July 1 seems a reasonable time frame to shoot for.