On Sun, Jan 10, 2010 at 10:06 PM, Adrian Lienhard <[email protected]> wrote:
> 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. > > +1. But...they main question is, do you know in which cases it breaks stuff? ONLY with overrides ? How many overrides do we have from external packages in Core ? > 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 > > It depends. For us it is easy. Buy there are other users, that have data in their image and maybe it is a little more complicated than download a package from squeaksource. > 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 <[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 > > > _______________________________________________ > 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
