I don't see any problem with making a 64-bit image available along with
the 5.1 release. After all, we went for many years supporting both 6504
and 6505 image format through several releases. The 32-bit and 64-bit
Spur images will be essentially the same image, just saved in a different
object format.

We do need to make sure that if someone chooses to load the 64-bit
version, that they are aware of the compatibility restrictions. But
that's nothing that we cannot handle with a good download page on
the web site, and I'm sure we can do that :-)

Dave


On Fri, Jul 15, 2016 at 12:34:04PM -0500, Chris Muller wrote:
> I'm talking about version numbers, not features.  In the past,
> whenever we broke backward compatibility, we incremented the major
> version number.  This is what we did with the 4.6 / 5.0 release.
> 
> Image conversion utilities notwithstanding, 64-bit essentially breaks
> backward compatibility, so "5.1" seems inappropriate for the new
> 64-bit release.  Do you object to your 6.0 features list being part of
> a "7.0" (or a 6.1, if we're not breaking backward compatibility with
> 64-bit 6.0)?
> 
> Also, it wasn't clear to me what you wanted to call the 32-bit version
> of "5.1".  Did you want to have have a 5.1-64 and a 5.1-32?
> 
> 
> On Fri, Jul 15, 2016 at 11:33 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Hi Chris,
> >
> >
> >> On Jul 13, 2016, at 9:40 AM, Chris Muller <asqueaker at gmail.com> wrote:
> >>
> >> I thought "6.0" was planned to be the 64-bit version of "5.1", and 5.1
> >> the 32-bit version of the same image contents...
> >
> > That's not what I tried to articulate at all.  What I want for 5.1 is essentially what Marcel outlines below, a cleaned up 5.0 with 64-bit support.
> >
> > For 6.0 I'm hoping we will do
> >
> > - the Sista bytecode set (with backwards compatibility support for the existing set).  This gives us 32k literals,
> > - FullBlockClosure, which means I depended method objects for blocks, and hence (slightly) faster block activation
> > - read-only objects and hence read-only literals
> >
> > These three provide the necessary support for the image-level Scorch adaptive optimiser.  This will be demonstrated at ESUG in Prague and productized by next year
> >
> > - collapsing of ContextPart and MethodContext onto Context.  The closure model does not need BlockContext so this is a nice simplification, one that Pharo has already released.
> >
> > Revised finalization.  Spur supports ephemerons which allow pre-mortem finalisation (they identify objects about to die, not the death of objects) and allow cycle-free addition of dependencies (which is how they identify objects about to die).  Since individual ephemerons must be identified (those whose keys are about to die) there is a finalisation queue into which the GC places such ephemerons. Spur also enqueues weak arrays that have lost efferent on the same queue.  Hence we can profitably reimplement many finalisation facilities:
> > - the current scheme has the VM signal a semaphore in any GC cycle that collects one or more referents of one or more weak arrays, and weak arrays are held in registries.  hence to finalise a single weak array requires finalising any and all weak arrays in the registries.  Instead, weak arrays can hold onto a manager directly through an inst var and have this object do the work, now meaning that only those weak arrays that lose references do work in each GC cycle.
> > - DependentsFields can be reimplemented to use a non-finalising ephemeron to attach dependents to objects without preventing their GC (unlike the current weak array approach)
> > - pre-mortem finalisation allows files to auto-finalise, hence flushing their contents before closing instead of finalising a copy which merely closes the file descriptor
> > - exiting the image should be arguably be done only after running a full GC and then draining the finalisation queue, and hence arguably there may need to be an emergency exit
> >
> > All of these together will impact code, breaking some old code, but always in simply fixable ways, and provide new facilities and pave the way to a substantial performance increase with Sista.  Hence these changes need IMO to be a full release, not a point release.
> >
> >>> On Wed, Jul 13, 2016 at 4:17 AM, Herbert K??nig <herbertkoenig at gmx.net> wrote:
> >>> Really exciting news!
> >>>
> >>> Herbert
> >>>
> >>>
> >>> -------- Urspr??ngliche Nachricht --------
> >>> Von: "marcel.taeumel"
> >>> Datum:13.07.2016 10:29 (GMT+01:00)
> >>> An: squeak-dev at lists.squeakfoundation.org
> >>> Betreff: [squeak-dev] [ANN] The Squeak 5.1 Release Plan
> >>>
> >>> Hey, there.
> >>>
> >>> I just want to inform all of you that we are in the middle of preparing the
> >>> next Squeak 5.1 release. We are working on automation for
> >>> generating/updating all release artifacts so that we are eventually able to
> >>> shorten our release cycle in the future. For this, we are using smalltalkCI
> >>> (thanks Fabio!), TravisCI, and AppVeyor.
> >>>
> >>> Here are the important dates:
> >>> * Feature Freeze on July 31, 23:59 AOE
> >>> * Code Freeze on August 14, 23:59 AOE
> >>> * Release between August 15 and 19
> >>>
> >>> As these dates suggest, our goal is to have the release before this year's
> >>> ESUG. However, there is another important Smalltalk-related event this year:
> >>> 20 years of Squeak. :-) Yeah! It was around October 1996, when the first
> >>> Squeak came into the world. ...having its own worlds. :D So, it would only
> >>> make sense to also have a special release for this birthday. For this, we
> >>> revived all of the cool multimedia content, known from Squeak 1 through
> >>> Squeak 3, and made it fit for the current Squeak code base. Oh, this is so
> >>> exciting. :-)
> >>>
> >>> Anyway, what's with Squeak 5.1 and 64-bit? Since the release of Squeak 5.0,
> >>> we've been working hard and made a lot of bug fixes and added some features
> >>> to improve the overall usability and robustness of the Squeak live
> >>> programming system. Meanwhile, the VMs improved as well. Cog's object format
> >>> "Spur" got more robust, the JIT improved, and the whole code base moved from
> >>> SVN to Git: https://github.com/OpenSmalltalk/opensmalltalk-vm.
> >>>
> >>> Still, what's up with 64-bit? We have working 64-bit VMs for Mac OS X and
> >>> Linux. Hence, we will take the chance and also release 64-bit bundles for
> >>> Squeak 5.1. Be informed that this means a new .image file. You cannot open a
> >>> 64-bit .image with a 32-bit VM and vice versa. This, however, is nothing
> >>> serious because we are working on an updated version of our SystemTracer to
> >>> convert back and forth. With limitations, of course. ;-) You cannot fill a
> >>> bottle of beer into a shot glass.
> >>>
> >>> What's up with the All-in-one? There will be the usual 32-bit all-in-one
> >>> package, which combines VMs for Linux, Mac OS X, and Windows. Since there
> >>> will be no 64-bit Windows VM within the next two months, we refrain from
> >>> creating an almost-all-in-one-32/64 package. This would only confuse the
> >>> users. In the future, we can arguably expand the concept of the All-in-one
> >>> to also contain 32-bit and 64-bit VMs and images.
> >>>
> >>> So, what are the prospective release artifacts for Squeak 5.1?
> >>> * All-in-one (Linux/Mac/Win) 32-bit
> >>> * Mac OS X App 32-bit, signed
> >>> * Mac OS X App 64-bit, signed
> >>> * Linux Bundle 32-bit
> >>> * Linux Bundle 64-bit
> >>> * Windows App (maybe with MSI Installer) 32-bit, maybe signed
> >>> * ZIP archive containing .image and .changes, no VM, no .sources
> >>>
> >>> We plan to also use the new release automation process for Squeak 5.0 and
> >>> update those release artifacts as well. We will update our squeak.org
> >>> Website but you will always find the artifacts on
> >>> http://files.squeak.org/5.0 and http://files.squeak.org/5.1 .
> >>>
> >>> :-)
> >>>
> >>> Best,
> >>> Marcel
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>> http://forum.world.st/ANN-The-Squeak-5-1-Release-Plan-tp4906439.html
> >>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
> >>