On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts
<mike@mjr104.co.uk> wrote:
> Ok...the problem is that I have just checked and this changes are only in
> 1.1 isn't it ?
>
> :(��� So...what we do ? we keep like this until 1.1 ?
oh sorry yes they are only in 1.1. �You just need to change version:
string using some string manipulation. �If you keep it in the same
format it will parse correctly by code that expects the 1.1 format.
On principle I did not backport the SystemVersion changes behaviour to
1.0 since it was already at the end of the cycle. However i just
migrated the data to work across core branches.
>
>>
>> and you can change the suffix as well, but personally i would not use
>> the date in the image name.
>>
>
> For the date you refer to year, month and number of version inside the month
> ?
yes I think it is too complicated a version scheme. The dev tag is
also synonymous with Pharo.
so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1
I would call it Pharo-1.0-10505-rc1. This is the same scheme that the
core image uses, and Pharo 1.1 will have this behaviour already using
#imageVersionString since it is in 1.1.
That's cool. I evaluate:
SystemVersion current version: 'Pharo-1.0-10505-rc1'
And seems to be almost what I want.� It would be cool (maybe not for 1.0, but for 1.1)� if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand:
coreVersion: � and version:
Then in System -> About, if I am in a core image I would see:
�PharoCore1.0rc1
Latest update: #10505
And if I am in Pharo I would see
Pharo1.0-10505-rc1dev10.01.1
PharoCore1.0rc1
Latest update: #10505
Right now, with what you told me is enought for 1.0, but maybe for 1.1 would be cool to have that.
what do you think ?
cheers
mariano
�
thanks,
Mike