> On 14 Dec 2015, at 13:03, Ben Coman <b...@openinworld.com> wrote: > > On Mon, Dec 14, 2015 at 7:27 PM, Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@gmail.com>> wrote: >> >>> On 14 Dec 2015, at 12:21, Ben Coman <b...@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