> 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

Reply via email to