Ok so that I know it and this is probably 3 changes of 500. I was thinking 
about what is the problem with 2.0 update.


>> But marcus we are doing update all the time because this is the way we push 
>> new updates daily.
>> So I do not understand why this would be different?
>> 
> 
> It happens due to strange things: updates that access the web and URLs 
> change, for example.
> Or in the past one problem was that it could overload squeak-source to load 
> for hours and hours packages…
> 
> And it takes quite some care to keep it going: when *really* bad things 
> happen, we now (once or twice in a year)
> upload a fixed image that is than taken as the base. If you want to support 
> “take pharo2 and update it to pharo3”,
> (or even, take Pharo3 half a year ago…), then we need to put *a huge* (very 
> huge) effort into making sure that
> we never ever upload a hand-fixed image. 
> This is a lot of work. 
> 
> And in addition, even that does not guarantee anything: you would need to 
> actually test it… 
> 
> 
> 
>>> 
>>>> no you dont do anything wrong, unfortunately from what I have been told 
>>>> the update process is broken. Right now the best choices is to download 
>>>> directly from pharo website 
>>>> 
>>> The problem is that how images are used is shifting: People used to use an 
>>> image for a long time, updating the base from time to time while their code
>>> was in the image.
>>> 
>>> These days, what people do is to have an automatic (and well defined) 
>>> process that build a fresh image on
>>>     -> base system is updated
>>>     -> Own code commit
>>> 
>>> So e.g. I never retain images after I finish something. I commit, wait for 
>>> the build system to tell me everything is green, and I throw the image
>>> away. Images are transient things. 
>>> 
>>> This in turn means nobody uses updating, and this means that it is not 
>>> tested. and everything not tested brakes after a while….
>>> (In turn, everything we want to be sure works needs to be tested after 
>>> every commit, but testing “updating every old version to the newest”
>>> is not really testable, anayway…)
>>> 
>>> When we move to an image-bootstrap for the development of Pharo itself (I 
>>> guess in Pharo4), we should really check what and how (and if) we
>>> support updating existing images, or if we declare the image to be 
>>> something that *always* be the result of a deterministic build process…
>>> 
>>>     Marcus
>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to