Allow or disable System Update in PharoDev images ?

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?

If that is the case I would disable it.

I assume this would be replaced by some Metacello 'update stream' ?

cheers,
Mike

2010/1/10 Mariano Martinez Peck <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I agree, it would be nice to have software update for the Pharo
images. But as long as it does not reliably work, I think it harms
more than it helps.

Adrian

BTW, I believe one should regularly start with a fresh image, so
starting from a new download should not be a big issue anyway

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 <[hidden email]>
>>> 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 <[hidden email]>:
>>>>> 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
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project