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