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