On 14 Dec 2015, at 13:03, Ben Coman <btc@openInWorld.com> wrote:

On Mon, Dec 14, 2015 at 7:27 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 14 Dec 2015, at 12:21, Ben Coman <btc@openinworld.com> wrote:

This is great news. Thanks Eliot and Esteban.  From the 2GB limit I
take this to be 32-bit Spur?

yes of course.
We are already working on 64bits spur but is not ready yet (it will be some point of 2016)


Is it feasible to jump the image build numbers to make that first
image requiring a new VM align on a 100s build numbers.  I see we are
currently 50496.    50500 is nice and distinctive, but even even 50600
would be fine if the last few 400s are consumed in the meantime.

mmm��� that I don���t know��� correlation of version numbers is usually important for us (for statistics purposes)��� also changing number generation is more annoying than you would think (that���s why we don���t  have 4.1, 4.2, etc.).
but well��� everything is possible, we���ll see :)

Or do we just append "-spur" to the build number - but there will be
no new builds without the "-spur" tag, and continue this up to Pharo 5
Release.  I am just thinking of making it easy to distinguish the
required VM when I want to open old builds to bisect which build
instorduced a bug.

again, harder than it seems (because releasing a version is stupidly-hard)��� I���m thinking on move all 50 pre-spur into a 49 directory (4.9), then all is correctly separated in file server. 
This is the easiest I can do it��� I think :)

Esteban


cheer -ben