On Jan 10, 2010, at 19:22 , Miguel Enrique Cob� Martinez wrote:
> El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribi�:
>> I would also rather disable it. We had numerous reports where this
>> failed. I think "the right way" to do it is to have a build server
>> that creates new Pharo images from the PharoCore version (i.e.,
>> "nightly builds"). Until we have this automated, one can always grab
>> an up to date PharoCore and build a Pharo image using the Metacello
>> configuration.
>
> But this means that the users that downloaded a prior Pharo will be
> left
> on the cold and they will not receive bug fixes, including grave bug
> fixes. They will be informed that must download a new version and move
> all their code to a new image.
>
> This could generate a lot of irritation on the users because maybe
> they
> are changing images just because their current image can't apply a
> one-line fix that could be distributed by the update stream.
>
> Big decision I know, but both options have good arguments.
> Maybe a BIG warning on pressing the System->Update indicating that the
> update *could* break something in the image and suggesting to save all
> their work to a monticello package and know the consecuences and then
> giving them a button to proceed with the update.
> So if someone doesn't want to update he/she can cancel. If the haven't
> saved, they cancel and save their work, then proceed with the
> update. If
> they have everything saved, just proceed with the update knowing the
> consequences. What do you think?
>
> Cheers
>
>
>>
>> Adrian
>>
>> On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote:
>>
>>> On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <
mike@mjr104.co.uk>
>>> wrote:
>>>
>>>> without its own update stream, or section in the update file, I
>>>> think
>>>> the effect of allowing the Pharo image to update itself based on
>>>> the
>>>> core update file would lead to an undefined result?
>>>>
>>>>
>>> Yes. Mostly due to overrides.
>>>
>>>
>>>> If that is the case I would disable it.
>>>>
>>>> I assume this would be replaced by some Metacello 'update stream' ?
>>>>
>>>>
>>> That's a good idea. I am not sure how to implement it, but for sure,
>>> it will
>>> be in a future ;) �Maybe 1.1
>>>
>>>
>>>> cheers,
>>>> Mike
>>>>
>>>> 2010/1/10 Mariano Martinez Peck <
marianopeck@gmail.com>:
>>>>> It is a simple question. Do we allow that or not. �Miguel wrote
>>>>> the pros
>>>> and
>>>>> cons:
>>>>>
>>>>> Pros
>>>>> - Can fix bugs after release
>>>>> - Can aply improvements to the image after release.
>>>>>
>>>>> Cons
>>>>> - Can mess the image of someone by overwriting some overridden
>>>>> method.
>>>>> - Can accidentally update more than intended in someone's image
>>>>>
>>>>>
>>>>> We have to take a decision.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Mariano
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>>
Pharo-project@lists.gforge.inria.fr
>>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>>
Pharo-project@lists.gforge.inria.fr
>>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>>
Pharo-project@lists.gforge.inria.fr
>>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cob�
>
http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
>
Pharo-project@lists.gforge.inria.fr
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project